E D R , A S I H C RSS

Full text search for "호출 규약 (calling convetion)"

호출 규약 (calling convetion)


Search BackLinks only
Display context of search results
Case-sensitive searching
  • EffectiveC++ . . . . 36 matches
          * inline: 함수 호출로 인한 오버헤드를 줄일수 있는.. 거시기. 궁금하면 책찾아보세요.
          * ''new를 호출할때 []를 이용했다면 delete의 호출시에도 []를이 용한다. 간단간단!''
         // 연산자 new가 충분한 메모리를 할당하지 못할 경우 호출될 함수
          int *pVigdataArray = new int [100000000]; // 100000000개의 정수공간을 할당할 수 없다면 noMoreMemory가 호출.
         // 호출들을 표준 operator new로 전달하는 것이다
         클래스 내에 operator=가 정의 되어 있지 않기 때문에, C++에서 default 치환 연산자를 호출한다.[[BR]]
          // b의 소멸자가 호출된다. 그러므로, a가 가리키던 data도 소멸되게 된다.
          // 복사 생성자가 정의 되지 않았기 때문에 C++에서 제공하는 default 치환 연산자 호출.
          // 그러나, c와 a는 같은 곳을 가리킨다. 그리고, c의 소멸자가 호출 되면 위에서 삭제된 곳을 다시한번
         doNothing(s); // deault 복사 생성자 호출. call-by-value로 인해
         // 그래서, doNothing이 수행을 마치면, localString은 여역을 벗어나고, 소멸자가 호출된다.
         객체들(string 객체)이 생성된 순서를 기억한다음 소멸자를 차례대로 호출해야 할것이다. 이런 overhead를 없애기 위해, [[BR]]
         모든 객체에 대해서 생성자와 소멸자의 호출 순서는 동일하게 되어 있고, 초기화 리스트에 나열된 순서는 무시된다.[[BR]]
         호출되지 않는다는 것이다. 위의 예에서, targetPtr이 삭제 될때 EnemyTank의 수가 제대로 조정되지 않는다는 것을 의미 한다.)[[BR]]
         치환의 오른쪽 부분이 String형이 아니라 char *형이기 때문에 컴파일러는 String의 생성자를 통해 임시 String객체를 만들어서 호출을 한다. 즉, 아래와 같은 code를 생성한다.
         컴파일러는 위와 같은 임시 객체를 만들려고 하지만, 임시 객체가 const라는 것에 주의. 그리고, operator=의 리턴형을 보면 String에 대한 레퍼런스를 돌려주기 때문에 리턴형이 일치하지 않게 된다. 그래서, error를 발생시킨다. 만약 error를 발생 시키지 않는다면, operator=이 호출되는 측에서 제공된 인자가 아니라 컴파일러가 발생시킨 임시 변수만 수정된다는 것에 놀랄것이다. --;[[BR]]
         보기와 같이 제대로 작동하지 않는 operator= 연산자이다. 그럼, 이것을 어떻게 고치면 좋을까? 이 문제를 해결하기 위해서는, 다음과 같이 Base클래스의 operator=연산자를 호출해 주면 된다. ( Derived 클래스의 operator= 연산자에서 x를 치환해 준다는 것은 허용되지 않기 때문에.)
         Derived 클래스의 복사 생성자를 보면 Base클래스의 멤버 변수는 초기화 시키지 않음을 알수 있다. 이런 문제를 피하기 위해서는 밑의 코드와 같이 Base클래스의 복사 생성자를 호출해 주면 된다.
         이젠 Derived클래스의 복사생성자를 호출해도 Base클래스의 멤버 변수역시 잘 복사 된다.
         === 항목 22. 값에 의한 호출보다는 레퍼런스에 의한 호출을 선호한다. ===
  • Android/WallpaperChanger . . . . 28 matches
          // 서비스를 생성할 때 호출
          // 서비스 시작할 때 호출. background에서의 처리가 시작됨.
          //onStart는 여러번 호출될 수 있기 때문에 식별자로 사용.
          // postDelayed : 일정시간마다 메소드 호출
          // 서비스의 종료시 호출
          // onDestroy가 호출되어 서비스가 종료되어도
          // postDelayed는 바로 정지되지 않고 다음 번 run 메소드를 호출.
          // 원격 메소드 호출을 위해 사용
          // 메서드 호출을 제공하지 않으면 null을 반환
         이 조언의 반대적 측면은 네이티브 메소드를 호출하는 것이 interpret방식의 메소드 호출보다 더 비용이 높다는 것입니다. 피할 수 있다면, 사소한 계산에는 네이티브 메소드를 사용하지 마십시오.
         전통적인 지혜에서는 Map을 사용해야 한다고 할 것입니다. Map 인터페이스를 구현한 어떤 것으로라도 구현체를 바꿀 수 있기 때문입니다. 전통적인 지혜는 전통적인 프로그래밍에는 맞습니다만, 임베디드 시스템에는 그다지 대단하지 않습니다. 인터페이스 참조를 통해 호출하는 것은 명확한 참조를 통한 가상 메소드 호출보다 2배 더 소요될 수 있습니다.
         여러분이 하는 일에 적합하여 HashMap사용을 선택했다면 Map으로 호출하는 것은 거의 가치가 없습니다. 코드를 리팩터링 해 주는 IDE의 가능성을 고려해 보더라도, Map으로 호출하는 것은 큰 가치가 없습니다. 여러분이 코드의 방향을 확신하지 못한다 해도 말입니다. (다시금 이지만, 공용 API는 예외입니다: 작은 성능 고려보다 좋은 API가 언제나 으뜸입니다.)
         만약 객체의 필드에 접근할 필요가 없다면, 여러분의 메소드를 정적(static)으로 만드세요. 가상 메소드 테이블을 필요로 하지 않기 때문에 그게 더 빠르게 불려집니다. 또한, 메소드 식별자를 보고 메소드 호출이 객체의 상태를 바꿀 수 없다고 말할 수 있으므로, 좋은 관습이 됩니다.
         안드로이드에서는 나쁜 생각입니다. 가상 메소드 호출은 인스턴스 필드 참조보다 더 비용이 높습니다. 일반적인 객체 지향 프로그래밍 관습에 따르거나, 공용 인터페이스에서 getter, setter을 가지는 것은 이치에 맞습니다. 그러나 클래스 내부에서는 언제나 직접적으로 필드 접근을 해야합니다.
         유사한 가이드라인은, 결코 "for"문의 두 번째 조건에서 메소드를 호출하지 말라는 것입니다. 예를 들어, 다음 코드는 간단하게 int 값으로 캐쉬 할 수 있는 경우임에도 큰 낭비가 되는 getCount()메소드를 매번 반복 마다 실행하게 됩니다:
         "final"으로 메소드나 클래스의 선언을 하는 것은 즉각적인 성능 이득을 주지는 못하지만, 특정한 최적화를 가능하게 합니다. 예를 들어, 컴파일러가 서브클래스에 의해 오버라이드될 수 없는 "getter"메소드를 알고 있다면, 메소드 호출을 inline화 할 수 있습니다.
         향상된 반복문(때로 "for-each"로 알려진 반복문)은 Iterable 인터페이스를 구현한 컬렉션들을 위해 사용될 수 있습니다. 이러한 객체들로, 반복자는 hasNext() 와 next()을 호출하는 인터페이스를 만들기 위해 할당됩니다. ArrayList의 경우 여러분이 직접 탐색하는 것이 좋을 수 있습니다만, 다른 컬렉션들에서는 향상된 반복문 구문이 명시적인 반복자의 사용과 동등한 성능을 보여줍니다.
         900 바이트의 클래스 파일 (Foo$Shrubbery.class) 로 변환됩니다. 처음 사용할 때, 클래스 초기자는 각각의 열거화된 값들을 표기화 하는 객체상의 <init>메소드를 호출합니다. 각 객체는 정적 필드를 가지게 되고 총 셋은 배열("$VALUES"라 불리는 정적 필드)에 저장됩니다. 단지 세 개의 정수를 위해 많은 코드와 데이터를 필요로 하게 됩니다.
         String.length() 호출 5
         빈 정적 네이티브 메소드 호출 5
  • MoreEffectiveC++/Miscellany . . . . 27 matches
         ''program in future tense''는, 변화의 수용하고, 준비한다. 라이브러에 추가될 새로운 함수, 앞으로 일어날 새로운 오버로딩(overloading)을 알고, 잠재적으로 모호성을 가진 함수들의 결과를 예측한다. 새로운 클래스가 상속 계층에 추가될 것을 알고, 이러한 가능성에 대하여 준비한다. 새로운 어플리케이션에서 코드가 쓰이고, 그래서 새로운 목적으로 함수가 호출되고, 그런 함수들이 정확히 동작을 유지한다. 프로그래머들이 유지 보수를 할때, 일반적으로 원래의 개발자의 영역이 아닌, 유지 보수의 몫을 안다. 그러므로, 다른 사람에 의해서 소프트웨어는 이해, 수정, 발전의 관점에서 구현하고 디자인된다.
         모든 클래스에서 할당(assignment), 복사를 잡아라. "비록 아무것도 하지 않는 것"이라도 말이다. 왜냐하면 그것들이 지금 할수 없는건 미래에도 할수 없다는 의미이다. 만약 이러한 함수들이 구현하기에 어렵게 한다면, 그것을 private로 선언하라. 미래에도 동작시키게 하지 않다는 의미다. 컴파얼러가 만들어내는 함수에 대한 모호한 호출을 할리가 없다. (기본 할당 생성자나 기본 복사 생성자가 종종 발생되는 것처럼)
         문제에 대한 한가지 접근으로 할당(assignment)연산자를 가상(virtual)로 선언하는 방법이 있다. 만약 Animal::operator= 가 가상(virtual)이면, 위의 경우에 할당 연산자는 정확한 Lizard 할당 연산자를 호출하려고 시도할 것이다. 그렇지만 만약 우리가 가상으로 할당 연산자를 선언했을때 다음을 봐라.
         liz1 = liz2; // const Lizard&를 인자로 하는 operator= 호출
         *pAnimal1 = *pAnimal2; // const Ainmal&인자로 가지는 operator= 연산자 호출
         이 함수는 rhs를 Lizard로 형변환 시킨다. 만약 형변환이 성공된다면 할당 연산자가 성공적으로 호출 될것이다. 반대라면 언급했던 bad_cast 예외가 발생된다.
         게다가 Lizard와 Chicken에 구현된 할당 연산자도 정확히 구현되기 불가능하다. 왜냐하면, 유도된 클래스에서 할당 연산자는 그들의 기초 클래스의 할당 연산자의 호출을 책임진다.
          Animal::operator=(rhs); // 에러! 사역(private) 인자의 함수를 호출하는 시도를 한다.
          // 의 할당을 위해 호출해야 한다.
         많은 면에서, C++와 C에서 컴포넌트를 만들때, 네가 하는 걱정은 C 컴파일러가 오브젝트 파일을 서투르게 처리 할때의 걱정과 같다. 다른 컴파일러들이 구현에 의존적인 요소들에 대하여 동일하지 않으면, 그런 파일들을 혼합해서 쓸 방법이 없다. (구현 의존 요소:int, double의 크기, 인자를 넘기고 받는 방법, 호출자와 호출간에 통신 ) 이러한 개발 환경에서 컴파일러들을 섞어서 사용하는 것에(mixed-compiler) 관한 실질적은 관점은 언어의 표준에 대한 노력에 의해서 아마 완전히 무시 된다. 그래서 컴파일러 A와 컴파일러 B의 오브젝트 파일을 안전하게 섞어서 쓸수 있는 신뢰성 있는 유일한 방법은, 컴파일러 A,B의 벤더들이 그들의 알맞는 output에 대한 product의 정보를 확실히 아는 것이다. 이것은 C++와 C를 이용하는 프로그램, 그런 모든 프로그램에 대하여 사실이다. 그래서 당신이 C++과 C를 같은 프로그램에서 섞어서 쓰기 전에는 C++와 C컴파일러가 알맞는 오브젝트 파일을 만들어 내야만 한다.
         그리고 당신의 코드는 일반적으로 사용하는 것처럼 drawLine을 호출하는 코들르 가진다. 그러한 각 호출마다 당신의 컴파일러가 mangle을 한 함수 이름을 호출 부분에 넣는다. 그래서 이론 코드를 쓰면,
         당신의 오브젝트 파일은 다음과 같은 모습의 함수 호출을 가진다.
         그렇지만 만약 drawLine가 C함수라면, drawLine 함수를 호출할때 drawLine으로 포함하는 컴파일러된 버전으로 오브젝트( 혹은 동적 링크 라이브러리 등) 파일에 포함되어 있다.;name mangle이 되지 않은 체로 되어 있다. 당신이 이 둘을 모두 섞어서 프로그램 하려고 노력하면, 에러가 날것이다. 왜냐하면 링커는 xyzzy의 호출되는 함수를 찾고, 그에 관한 함수가 없기 때문이다.
         이런 문제를 해결하기 위하여, C++ 컴파일러에게 해당 함수에 name mangle을 수행하지 않도록 알려야 할 방법이 필요하다. C든, assempler, FORTRAN, Lisp, Forth나 니가 가진 무슨 언어간에, 다른 언어에서 작성되어진 name mangle 처리된 함수를 원할수 없다.(예, 이 언어들에 COBOL도 들어가겠지만 당신이 쓰는가?) 결곡, 만약 C함수인 drawLine을 호출하면 그것은 진짜로 drawLine을 호출하고, 당신의 오브젝트 코드역시 그 이름 그대로 변화없이 사용한다.
         extern "C"를 쓰는것을 당연시 생각하는 함정에 빠지지 마라, extern "Pascal" 이나 extern "FROTRAN" 만이 쓰이는 경우도 있다.하지만 최소한 표준은 아니다. 가장 좋은 방법인 extern "C"는 C에서 작성된 함수들과 관계 있다는 것을 확신하는건 아니지만, 만약 C에서 작성된 것처럼 해당 함수를 호출할 수 있다는 의미이다. (기술적으로 extern "C" 는 C와의 연결을 가진 함수를 의미하지만, 꼭 그런것 만은 아니다. 그렇지만 name mangle을 방지 한다는 것 만은 확실하다.)
         때때로 C에 main 작성이 더 가치 있다고 보인다. - 대다수 프로그램이 C이고, C++이 단지 라이브러리 지원 이라면 이라고 말해라. 그렇기는 하지만, C++ 라이브러리는 정적(static) 객체(object)를 포함하는 것이 좋다.(좋은 기능이 많다는 의미) (만약 지금 없다해도 미래에 어쩌면 있을지 모르지 않는가? Item 32참고) 그래서 가능하다면 C++에서 main을 작성은 좋은 생각이다. 그것은 당신의 C코드를 제작성 하는것을 의미하지는 않는다. 단지 C에서 쓴 main을 realMain으로 이름만 바꾸고, main의 C++버전에서는 realMain을 호출한다.:
         만약 C++에서 main을 작성할수 없다면 문제가 된다. 왜냐하면, 정적(static) 객체 호출을 위한 생성자, 파괴자에 대하여 이식성에 확신을 줄수 없기 때문이다. 이것은 모든것을 잃는다는 의미는 아니다. 단지 좀더 할일이 많아 진다는 것을 의미한다. 컴파일러 밴더들은 이러한 문제를 잘 알고 있다. 그래서 거의 대부분의 벤더들은 static initialization, destruction을 위해서 몇가지의 언어와 관계없는 기술을 제공한다. 이에 관한 정보는 당신의 컴파일러의 문서를 참조하거나, 벤더들에게 문의해라
         동적 메모리 할당(dynamic memory allocation:이하 동적 메모리 할당)에 관한 문제가 우리에게 주어진다. 일반적인 규칙은 간단하다.:C++ 에서 new, delete 부분 (Item 8참고) 그리고 C 프로그래밍 에서는 malloc(그리고 그것의 변수들) 과 free이다. malloc으로 얻은건 free로, new로 얻은건 delete로 해재하는한 모든 것이 올바르다. 그렇지만, new로 할당된 메모리 영역을 가리키는 포인터를 free로 해제 시키는 호출은 예측 못하는 수행을 가지고 온다. 마찬가지로 malloc로 얻은 것을 delete로 해제하는 것도 예측할수 없다. 그렇다면, 이를 기억하기 위한 방법은 new와 delete, malloc와 free를 엄격하게 구분해야 하는 것이다.
         메모리 leak를 피할려면, strdup 내부에서 할당된 메모리를 strdup의 호출자가 해제해 주어야 한다. 하지만 메모리를 어떻게 해제 할것인가? delete로? free로? 만약 strdup를 당신이 C 라이브러리에서 불렀다면, free로, C++ 라이브러리에서 불렀다면 delete로 해야 한다. 무엇이 당신은 strdup 호출후에 무엇이 필요한가, 시스템과 시스템 간에 뿐이 아닐, 컴파일러, 컴파얼러 간에도 이건 문제를 일으킬수 있다. 그러한 이식성의 고통의 감소를 위해, 표준 라이브리에서 불러야 하지 말아야할 함수, 대다수 플렛폼에 종속적으로 귀속된 모습의 함수들을 부르지 않도록 노력하라.
         list 객체를 찾기 위한 호출을 위해서, 당신은 list의 가장 처음 인자와 list와 가장 마지막의 인자를 가리키는 iterator가 필요하다. 리크트 클래스에 의한 몇가지의 도움 될 기능들을 제외하고, 이것은 어려운 문제이다. 왜냐하면 당신은 list가 어떻게 구현되었는 가에 관한 정보가 없기 때문이다. 다행 스럽게다 리스크(list,모든 STL의 container들과 같이) 시작과 끝을 제공하는 멤버 함수로서 해결한다. 이 멤버 함수는 당신이 원하는 iterator 반환하고 위의 예제에서 해당 iterator 두가지를 찾을수 있다.
  • CToAssembly . . . . 26 matches
         C/C++같은 고급언어의 컴파일러는 고급언어를 어셈블리코드로 변환할 수 있다. GNU C/C++ 컴파일러의 -S 옵션은 프로그램 소스에 해당하는 어셈블리코드를 생성한다. 반복, 함수 호출, 변수 선언과 같은 기본적인 구조가 어셈블리어로 어떻게 대응하는지 알면 C 내부를 이해하기 쉽다. 이 글을 이해하기위해서는 컴퓨터구조와 Intel x86 어셈블리어에 익숙해야 한다.
         프로그램의 첫번째 줄은 주석이다. 어셈블러 지시어 .globl은 심볼 main을 링커가 볼 수 있도록 만든다. 그래야 main을 호출하는 C 시작라이브러리를 프로그램과 같이 링크하므로 중요하다. 이 줄이 없다면 링커는 'undefined reference to symbol main' (심볼 main에 대한 참조가 정의되지않음)을 출력한다 (한번 해봐라). 프로그램은 단순히 레지스터 eax에 값 20을 저장하고 호출자에게 반환한다.
         복잡한 프로그램을 만들때 우리는 해결할 문제를 체계적으로 나눈다. 그리고 필요할때마다 호출할 함수를 작성한다. 목록 3은 어셈블리어 프로그램의 함수 호출과 반환을 보여준다.
         call 명령어는 실행을 함수 foo로 옮긴다. foo의 ret 명령어는 실행을 다시 main의 호출 다음에 나오는 명령어로 옮긴다.
         일반적으로 함수는 함수가 사용할 변수들을 정의한다. 이 변수들을 유지하려면 공간이 필요하다. 함수 호출시 변수값을 유지하기위해 스택을 사용한다. 프로그램 실행중에 반복되는 재귀호출시(recursive call) activation record가 유지되는 방법을 이해하는 것이 중요하다. esp나 ebp같은 레지스터 사용법과 스택을 다루는 push와 pop같은 명령어 사용법은 함수호출과 반환방식을 이해하는데 중요하다.
         목록 3에서 명령어 call foo는 호출을 마친후 실행할 명령어의 주소를 스택에 넣고 foo로 분기한다. 함수는 ret에서 끝나고, 실행을 스택 최상위에서 가져온 주소에 있는 명령어로 옮긴다. 물론 스택 최상위에 유효한 반환주소가 있어야 한다.
         먼저 스택포인터의 값을 기준포인터 레지스터(base pointer register) ebp에 복사한다. 기준포인터는 스택의 다른 위치를 접근할때 사용할 고정된 기준점이다. foo를 호출한 코드에서도 ebp를 사용하므로, 값을 esp 값으로 대체하기 전에 스택에 복사한다. 명령어 subl $4, %esp는 스택포인터를 감소하여 정수를 담기위한 (4 바이트) 공간을 만든다. 다음 줄은 값 10을 ebp에서 4를 뺀 (4 바이트) 주소에 복사한다. 명령어 movl %ebp, %esp는 스택포인터를 foo 시작시 가졌던 값으로 되돌리고, popl %ebp는 기준포인터 레지스터의 값을 되돌린다. 스택포인터는 이제 foo를 시작하기 전과 같은 값을 가진다. 아래 표는 main 시작과 목록 4의 (main에서 반환을 제외한) 각 명령어 실행후 레지스터 ebp, esp와 3988에서 3999까지 스택 주소의 내용이다. 우리는 main의 첫 명령어 실행전에 ebp는 값 7000, esp는 값 4000을 가지며, 스택 주소 3988에서 3999까지 임의의 값 219986, 1265789, 86이 저장되있다고 가정한다. 또, main에서 call foo 다음에 나오는 명령어의 주소가 30000이라고 가정한다.
         함수로 파라미터를 전달하기위해 스택을 사용할 수 있다. 우리는 함수가 eax 레지스터에 저장한 값이 함수의 반환값이라는 (우리가 사용하는 C 컴파일러의) 규칙을 따른다. 함수를 호출하는 프로그램은 스택에 값을 넣어서 함수에게 파라미터를 전달한다. 목록 5는 sqr이라는 간단한 함수로 이를 설명한다.
         sqr의 첫번째 줄을 주의있게 살펴라. 함수를 부르는 측은 ebx의 내용을 스택에 넣고 명령어 call을 실행한다. 호출시 반환주소를 스택에 넣는다. 그리고 sqr는 스택 최상위에서 4 바이트 떨어진 곳에서 파라미터를 읽을 수 있다.
         반대도 매우 간단하다. 목록 7은 C 함수 print와 이 함수를 호출하는 어셈블리어를 보여준다.
         = 시스템호출(system call) =
         프로그램이 어셈블리로 수학 알고리즘만을 구현하지 않는다면, 입력을 받고, 출력하고, 종료하는 등 어떤 작업이 필요하다. 이를 위해 운영체제 서비스를 호출해야 한다. 사실 운영체제 서비스를 제외하고는 여러 운영체제간의 어셈블리어 프로그래밍이 매우 비슷하다.
         리눅스에는 시스템호출을 하는 두가지 일반적인 방법이 있다: C 라이브러리 (libc) wrapper를 통하거나, 직접.
         Libc wrapper는 시스템호출 규칙이 변경되는 경우 프로그램을 보호하고, 커널에 그런 시스템호출이 없는 경우 POSIX 호환 인터페이스를 제공하기위해 만들어졌다. 그러나, 유닉스 커널은 보통 거의 POSIX에 호환한다: 즉 대부분의 libc "시스템콜"의 문법은 실제 커널 시스템호출의 문법과 (반대로도) 정확히 일치한다. 그러나 libc를 버리지않는 이유는 시스템콜 wrapper외에 printf(), malloc() 등 함수도 있기때문이다.
         리눅스 시스템호출은 int 0x80을 통해 한다. 리눅스는 일반적인 유닉스 호출 규칙과 다른 "fastcall" 규칙을 사용한다. 시스템함수 번호는 eax에, 아규먼트는 스택이 아닌 레지스터를 통해 전달한다. 따라서 ebx, ecx, edx, esi, edi, ebp에 아규먼트 6개까지 가능하다. 아규먼트가 더 있다면 간단히 구조체를 첫번째 아규먼트로 넘긴다. 결과는 eax로 반환하고, 스택을 전혀 건드리지 않는다.
         명령어 cc -g fork.c -static으로 프로그램을 컴파일한다. gdb 도구에서 명령어 disassemble fork를 입력한다. fork에 해당하는 어셈블리코드를 볼 수 있다. -static은 GCC의 정적 링커 옵션이다 (manpage 참고). 다른 시스템호출도 테스트해보고 실제 어떻게 함수가 동작하는지 살펴봐라.
         리눅스 시스템호출에 대한 최신 문서가 많아서 여기에 반복하지 않겠다.
         GCC의 최적화는 asm 표현이 있더라도 실행시간을 최소화하기위해 프로그램 코드를 재배열하고 재작성하려고 시도한다. asm의 출력값을 사용하지 않는다고 판단하면, asm과 아규먼트 사이에 키워드 volatile이 없는 한 최적화는 명령어를 생략한다. (특별한 경우로 GCC는 출력 연산수가 없는 asm을 반복문 밖으로 옮기지 않는다.) asm은 예측하기 힘든 방식으로, 심지어 호출간에도, 옮겨질 수 있다. 특별한 어셈블리 명령어 순서를 보장하는 유일한 방법은 모든 명령어를 모두 같은 asm에 포함하는 것이다.
         감싸인 함수는 감싸는 함수에 지역적이다(local). 즉, 감싸는 함수가 감싸인 함수의 포인터를 제공하지 않는다면 감싸는 함수 밖에서 감싸인 함수를 호출할 수 없다.
  • HardcoreCppStudy/첫숙제/ValueVsReference/변준원 . . . . 25 matches
         값에 의한 호출
         참조에 의한 호출
         ▶ 값에 의한 호출(Call by Value)
         호출된 함수는 형식 매개 변수의 기억 장소를 별도로 유지.
         함수를 호출하는 프로그램의 실 인수 값을 호출된 함수의 형식 인수에 복사해서 다른 지역 변수들과 동일하게 취급.
         값에 의한 호출 기법에서는 실인수의 값이 절대로 변하지 않음.
         ▶ 참조에 의한 호출 ( Call by Reference )
         참조에 의한 인수 전달 기법은 실 매개 변수의 주소를 호출된 함수에 대응하는 형식 매개 변수에 보내는 방법.
         참조에 의한 호출(call by reference, call by address, call by location) 방법은 가인수의 값을 변경시키면 실인수의 값도 변경
         정의,선언,호출이 엄격히 구분되며 Compiler에 의해 처리되어 object file을 만들며 분할 Pro
          - 값에 의한 호출(Call by value)
          - 포인터 참조에 의한 호출(Call by pointer reference)
          - 참조에 의한 호출(Call by reference)
         일반함수에서 정의, 선언, 호출에 대해 예를 들면,
          result = power(base, exponent); // 함수의 호출
         값에 의한 호출방법(Call by value )
         : 매개 변수의 전달시 매개변수의 값을 전달하는 것으로 실매개변수가 호출된 함수에 의해 영향을
          test(a,b); // 함수 호출
         결국 실매개변수가 호출함수에 의해 값이 변하지 않는다는 것을 알 수 있습니다.
         포인터 참조에 의한 호출(Call by point reference)
  • MoreEffectiveC++/Efficiency . . . . 25 matches
         String 복사 생성자의 적용시, s2는 s1에 의하여 초기화 되어서 s1과 s2는 각각 "Hello"를 가지게된다. 그런 복사 생성자는 많은 비용 소모에 관계되어 있는데, 왜냐하면, s1의 값을 s1로 복사하면서 보통 heap 메모리 할당을 위해 new operator(Item 8참고)를 s1의 데이터를 s2로 복사하기 위해 strcpy를 호출하는 과정이 수행되기 때문이다. 이것은 ''''eager evaluation''''(구지 해석하면 '''즉시 연산''' 정도 일것이다.) 개념의 적용이다.:s1의 복사를 수행 하는 것과, s2에 그 데이터를 집어넣는 과정, 이유는 String의 복사 생성자가 호출되기 때문이다. 하지만 여기에는 s2가 쓰여진적이 없이 새로 생성되는 것이기 때문에 실제로 s2에 관해서 저런 일련의 복사와, 이동의 연산의 필요성이 없다.
          cout << s[3]; // operator []를 호출해서 s[3]을 읽는다.(read)
          s[3] = 'x'; // operator []를 호출해서 s[3]에 쓴다.(write)
         첫번째 operator[]는 문자열을 읽는 부분이다,하지만 두번째 operator[]는 쓰기를 수행하는 기능을 호출하는 부분이다. 여기에서 '''읽기와 쓰기를 구분'''할수 있어야 한다.(distinguish the read all from the write) 왜냐하면 읽기는 refernce-counting 구현 문자열로서 자원(실행시간 역시) 지불 비용이 낮고, 아마 저렇게 스트링의 쓰기는 새로운 복사본을 만들기 위해서 쓰기에 앞서 문자열 값을 조각내어야 하는 작업이 필요할 것이다.
         min, max, avg에 함수는 현재의 해당 collection의 최소값, 최대값 평균을 반환하는 값이라고 생각해라, 여기에서 이들이 구현될수 있는 방법은 3가지 정도가 있다. eager evaluation(즉시연산)을 이용해서 min, max, avg가 호출될때마다 해당 연산을 하는 방법. lazy evaluation(게으른연산)을 해서 해당 함수값이 반환하는 값이, 실제로 연산에 필요할때 마지막에 계산에서 연산해서 값을 얻는 방법. 그리고 over-eager evaluation(미리연산)을 이용해서 아예 실행중에 최소값, 최대값, 평균값을 collection내부에 가지고 있어서 min, max, avg가 호출되면 즉시 값을 제공하는 방법-어떠한 계산도 필요 없이 그냥 즉시 돌리는거다. 만약 min, max, avg가 자주 호출된다면 collection의 최소값, 최대값, 평균값을 이용하는 함수들이 collection 전역에 걸쳐서 계산을 필요로 할수 있다. 그렇다면 이런 계산의 비용은 eager,lazy evaluaton(게으른연산, 즉시연산)에 비하여 저렴한 비용을 지출하게 될것이다.(필요값이 즉시 반환되니)
         STL코드를 자세히 알고 싶어서 촛점을 벗어나지 말아라. Item 35 보면 좀 확실히 알게 될것이다. 대신에 이 함수의 전체적인 기능에 촛점을 맞추어 보자.현재 이 방법은 비교적 비싼 데이터 베이스의 쿼리(query)문에대한 비용대신에 저렴한 메모리상의 데이터 베이스 구조에서 검색을 하는 것으로 교체하는걸로 볼수 있다. 개인 방번호에 대한 호출이 한벙 이상일때 findCubicleNumber는 개인방 번호에 대한 정보 반환의 평균 비용을 낮출수 있다. (한가지 조금 자세히 설명하자면, 마지막 구문에서 반환되는 값 (*it).second이 평범해 보이는 it->second 대신에 쓰였다. 왜? 대답은 STL에 의한 관행이라고 할수 있는데, 반환자(iterator)인 it은 객체이고 포인터가 아니라는 개념, 그래서 ->을 it에 적용할수 있다라는 보장이 없다. STL은 "."과 "*"를 interator상에서 원한다. 그래서 (*it).second라는 문법이 약간 어색해도 쓸수 있는 보장이 있다.)
          new를 호출해서 충분한 메모리를 확보한다. 그렇게 해서 index를 활성화 시킨다.;
         이러한 접근은 new를 배열의 증가 때만 부르는 간단한 방법 이지만 new는 operator new(Item 8참고)를 부르고, operator new(그리고 operaotr delete)는 보통 이 명령어들은 비용이 비싸다. 그것의 이유는 일반적으로 OS, 시스템 기반의 호출(System call)이 in-process 함수호출 보다 느린게 되겠다. (DeleteMe OS를 배워야 확실히 알겠다 이건) 결과적으로 가능한 system 호출(system call)을 줄여 나가야 한다.
         C++ 내에서의 진짜 temporary객체는 보이지 않는다.-이게 무슨 소리인고 하니, 소스내에서는 보이지 않는다는 소리다. temporary객체들은 non-heap 객체로 만들어 지지만 이름이 붙지를 않는다. (DeleteMe 시간나면 PL책의 내용 보충) 단지 이름 지어지지 않은(unnamed)객체는 보통 두가지 경우중에 하나로 볼수 있는데:묵시적(implicit) 형변환으로 함수호출에서 적용되고, 성공시에 반환되는 객체들. 왜, 그리고 어떻게 이러한 임시 객체(temporary objects)가 생성되고, 파괴되어 지는지 이해하는 것은 이러한 생성과 파괴 과정에서 발생하는 비용이 당신의 프로그램의 성능에 얼마나 성능을 끼칠수 있는가 알아야 하기때문에 중요한 것이다.
         임시 객체(temporary objects)가 함수 호출이 성공된후 만들어지는 경우를 첫번째로 생각해 보자. 이것은 함수에 인자를 전달할때 서로간에 인자들의 형(type)가 맞지 않게 묶여(bind)진 경우에 일어 난다. 예를 들자면, 다음과 같은 문자열에서 어느 한글자가 출현하는 객수를 세는 함수를 생각해 보자
         countChar을 호출하는 곳을 보라. 처음에 구문에서 char 배열이 함수로 전달된다. 하지만 함수의 인자는 const string& 이다. 이런 호출은 오직 형(type)이 알맞지 않은것이 제거되거나 당신의 컴파일러는 훌륭히도 string 형의 임시 객체(temporary object)를 만들어서 그러한 맞지 않는 형문제를 제가하면 성공할수 있다. 그러한 임시 객체는 string 생성자가 buffer인자를 바탕으로 초기화 된다. 그러면 constChar의 str인자는 임시(temporary) string 객체를 받아들인다.(bind-bound) countChar이 반환될때 임시(temporary)객체는 자동 소멸된다.
         해당 함수의 반환 인자(const Number)는 임시물(temporary)이다. 왜냐하면 그것은 아무런 이름도 가지기 않기 때문이다.:단지 함수의 반환되는 값일 뿐이다. 당신은 반드시 operator+가 호출될때 해당 객체의 생성, 삭제에 관한 비용을 지불해야만 한다. (반환 값이 const인것에 관한 이유를 알고 싶다면 Item 6을 참고하라)
         객체를 반환하는 함수는 효율적으로 만드는 노력을 파괴한다.(DeleteMe 약간 이상) 왜냐하면 값으로의 반환(by-value) 같은 생성자와 파괴자가 암시적으로 호출되는 녀석을 포함하는 것들은 제거될수 없기 때문이다. 이 문제는 간단하다:정확한 반응이나 그렇지 않았다는 것을 알려주는 객체를 함수가 리턴하는 것이다. 만약 그러하다면 반환된 객체를 제거할 방법은 존재하지 않는다.
         그것은 또한 의문을 자아 낸다. 호출자가 함수에 의해 반환된 포인터를 바탕으로 객체를 제거 해야 하는거? 이러한 대답에 관해서 보통은 "네" 이고 보통은 자원이 새어나가는(Resource leak)것을 발생 시킨다.
         한걸음 뒤로 물러서서, 우리의 목표는 형변환 이 아닌 operator+를 UPInt와 int구분의 혼합으로 호출할수 있게 만들수 있음을 알수 있다. 암시적 형변환의 문제가 끝났것 같다. 그러면, 혼란스런 의미에 종지부를 찍어 보자. 여기 operator+의 수행을 성공시키는 또 다른 혼합된(mixed-type) 호출 방식이 있다. 그것은 처음 시도한 방법에서 암시적 형변환을 제거해 줄것이다. 만약 우리가 UPInt와 int를 합을 할수 있기를 원한다면 우리는 그걸 전부다 그렇게 그대로 만든다. 몇개의 함수를 각기 다른 인자 형(parameter type)으로 overload해서 선언해 버리는 것이다.
          result = a + b + c + d; // 아마 이 연산에서는 각 operaotr+를 호출할때 발생하는
         T(lhs) 라는 표현은 T의 복사 생성자를 호출한다. 이것은 lhs와 동일한 값을 가지는 임시 객체를 생성한다. 이 임시 객체는 operator+=의 rhs로서 쓰이고, 그것은 operator+가 반환하는 결과 값이 된다. 이 코드는 필요없는 비밀(cryptic)로 보인다. 이것 처럼 하는 것이 더 낳지 않을까?:
         가상 함수가 호출될때 해당 코드는 함수가 불리는 객체에서 동적 형(dynamic type)으로 반응해서 실행된다.;포인터의 형(type)이나 객체의 참조는 중요하지 않다. 어떻게 컴파일러는 이러한 행동을 효율적으로 제공할수 있을까? 대다수의 적용 방법(implementations)은 ''virtual table''(가상 함수 테이블)과 ''virtual table pointer''(가상함수테이블 포인터)를 제공한다. virtual table과 virtual table pointer는 일반적으로 각자 ''vtbls''과 ''vptrs'' 로 대신 부를수 있다.
  • Cpp에서의멤버함수구현메커니즘 . . . . 21 matches
          * 다음 소스에서는 die메소드에서 자신을 삭제해줍니다. 그런데. 삭제되고도 뻔뻔스럽게 자신의 메소드를 호출하네요. 어떻게 된것일까요? 알아봅시다.
          cout << endl << ":::::: Case 3 - 포인터 NULL로 하고 메소드 호출하기 " << endl;
         :::::: Case 3 - 포인터 NULL로 하고 메소드 호출하기
          foo1->sayHello(); // 호출이 된다?
         ==== Case2 - 포인터 NULL로 하고 메소드 호출하기 ====
         여기까지가, class 와 struct 키워드가 하는 동일한 작업입니다. 그리고, class 에는 몇가지 더 생각해야 하는데, 그중 하나가 foo 를 이용해서 어떠한 member 함수를 호출할 수 있는가 입니다.
         그러나, 컴파일러인 우리는 이 정보를 지역 변수이든, new 로 할당이든 컴파일 시간에 인자의 type을 보고 함수 호출 유효성을 확인하고, 적절한 함수 포인터를 함수 호출하는 부분에 넣어 줄수 있습니다. 그리고 실행할 수 있는데 이 과정을 두번째에서 설명합니다.
         자 계속 우리는 컴파일러 입니다. 컴파일러인 우리는 member 함수 호출 부분을 함수의 실행코드를 가리키는 함수 포인터로 모두 교체하였습니다. 그리고 인간으로 돌아옵시다.
         C++ 표준안에서 전역에서 함수 호출과, instance에 귀속된 멤버 함수들의 호출을 가리지 않습니다. 함수 선언과 멤버 함수 선언의 함수 실행 코드는 모두 동일 방법으로 선언되고, 모두 동일한 메커니즘의 함수 포인터를 이용해서 호출합니다.
         라는 형태의 함수로 선언하고, 실행할수 있도록 만듭니다. 그리고, 호출한다면 {{{~cpp Foo*}}} 부분에
          사족. 이러한 사연이 class내에서 static 멤버 함수를 선언하고 instance에서 호출할때 instance 의 멤버 변수에 접근하지 못하는 이유가 됩니다. static 함수로 선언 하면 묵시적으로 pointer 를 세팅하지 않고 함수를 호출합니다.
         이렇게 나옵니다. (C++ 주석 빼고) 위에서 문제시 되는 부분은, 후반의 두가지 {{{~cpp sayHello() 와 sayMyId()}}} 일겁니다. 둘째 설명의 member 함수를 호출하는 메커니즘을 이해했다면
         형태로 호출된다는 것을 짐작할 수 있을 겁니다. 하지만 두 함수는 다른 점이 있습니다.
         과 같이 잘 동작합니다. 호출 형태가
          * C++ 에서 class 의 멤버 함수를 호출할때 멤버 함수의 첫인자를 해당 class 의 instance pointer 로 묵시적으로 선언되고 호출된다.
          * 위의 호출시에 pointer 의 유효성은 확인하지 않는다.
  • MoreEffectiveC++/Exception . . . . 20 matches
         파괴자 호출은 두가지의 경우가 있다. 첫번째가 'normal'상태로 객체가 파괴되어 질때로 그것은 보통 명시적으로 delete가 불린다. 두번째는 예외가 전달되면서 스택이 풀릴때 예외 처리시(exception-handling) 객체가 파괴되어 지는 경우가 있다.
         자 이건 괜찮아 보인다. 하지만 저 logDestruction상에서 예외가 발생한다면 어쩌게 할것인가? 해당 소스는 Session의 파괴자 안에서는 예외를 잡지 못한다. 그래서 해당 파괴자를 호출한 자에게 예외를 던진(전달한)다. 그렇지만 다른 에러들이 던져진 상황에서 파괴자가 스스로 자신을 부른거라면 함수의 종료가 자동으로 이루어지기를 원할 것이다. 그리고 당신의 프로그램은 이쯤에서 머추어 버릴 것이다. -해석이 이상하군, 암튼 다른 예외 처리시에 세션 파괴자 로그시 예외가 발생한다면 프로그램이 멈춘다는 소리다.
         == Item 12: Understand how throwing an exception differs from passing a parameter or calling a virtual function ==
         그래서 아마 함수호출에서 인자 전달과 과 예외가 전달되는 것이 기본적으로 같은것이라고 생각 할지도 모른다. 분명 둘은 비슷한 면이 있다. 하지만 중요한 차이점 역시 존재 한다.
         자, 비슷한 면은 언급해보면, 함수 예외 모두 에 인자를 전달할때 세가지로 전달할수 있다. 값(by value)이냐 참조(by reference)냐, 혹은 포인터(by pointer)냐 바로 이것이다. 하지만 이 함수와 예외에서의 인자의 전달 방식은 구동 방법에서 결정적인 차이점을 보인다. 이런 차이점은 당신이 함수를 호출할때 최종적으로 반환되는 값(returns)이 해당 함수를 부르는 위치로 가지만, 예외의 경우에 throw의 위치와 return의 위치가 다르다는 점에서 기인한다.
         localWidget이 operator>> 로 전달될때는 복사의 과정이 일어나지 않는다. 대신 operator>> 안의 참조 w가 localWidget과 묶여서 어떠한 과정을 처리하게 된다. 하지만 예외의 처리에서 localWidget은 좀 다른 이야기를 만들어 나간다. 예외가 값이나, 참조를 잡든 잡지(pointer는 잡지 못한다.) 않든 상관 없이 localWidget의 사본이 만들어지고, 그 사본은 catch로 저낟ㄹ 된다. 왜냐하면 passAndThrowWidget의 영역을 벗어나면 localWidget의 파괴자의 호출이 되기 때문에 반드시 이렇게 되어야 한다. 이것은 C++ 에서 예외는 항상 사본으로 전달된다는 이유가 된다.
         주석에 되어 있는데로, 생각해 보라. throw가 복사생성자를 호출하지 않아서 효율적이다. 그리고 throw는 어떠한 형이든 예외를 전달한는데 상관하지 않는다. 하지만, 사실 예외자체가 그 형에 맞게 던져지므로 걱정이 없다. 하지만 catch문에서 예외를 던지는 객체의 형태를 바꿀 필요성이 있을때 후자를 사용해야 겠다.
         반대로 가상함수를 부를때 일어나는일이 있다. 당신이 가상함수를 호출하면 함수는 해당 객체의 가장 합당한 함수를 dynamic으로 찾아낸다. 이것은 '''최고로 적합한 것(best fit)'''을 의미하지 '''가장 처음에 찾아 지는 것(first fit)'''을 의미하는 것이 아니다. 위의 소스를 반대로 한다면
         unexpected에 관련한 기본적인 행동은 terminate를 호출해서 terminate내에서 abort를 호출로 강제로 프그램을 멈추게 한다. 이 의미는 바로 abort는 프로그램을 종료할때 깨끗이 지우는 과정을 생략하기 때문에 활성화된 스택 프레임내의 지역 변수는 파괴되지 않는다.(즉, 프로그램이 멈추고 디버그시 그 상황에 현재의 자료 값을 조사할수 있다는 의미). 그래서 예외 처리의 명세을 어긴 문제는 상당히 심각한 상황이나, 거의 발생하지 않은 상황이다. 불행히도 그런 심각한 상황을 이르게 하는 함수 작성이 용이하다는게 문제이다. 컴파일러는 오직 예외 명세에 입각한대로 부분적으로 예외 사용에 관한 검사를 한다. 예외가 잡을수 없는것-언어 표준 상에서 거부하는(비록 주의(wanning)일지라도) ''금지하는'' 것- 은 함수를 호출할때 예외 명세에서 벗어나는 함수일것이다.
         당신의 컴파일러가 예외 처리규정에 만족하지 않은 루틴을 가진 함수의 코드를 호출하는데 별 무리없다고, 그러한 호출이 아마 당신의 프로그램에서 프로그램의 중지를 유도하기 때문에 당신은 소프트웨어를 만들때 최대한 그런 만족되지 않은 호출을 최소화 하도록 결과를 유도해야 할것이다. 시작시 가장 좋은 방향은 템플릿상에서의 예외 스펙를 최대한 피하는 것이다. 자 다음의 어떠한 예외도 던지지 않은 템플릿을 생각해 보자.
          * 두번째로 당신은 unexpected호출을 막기위하여 부족한 예외 명세의 규정으로 인하여 불리는 함수상에서 예외 명세를 생략할수 있다.
         이 코드에서 makeCallBack에서 func을 호출하는것은 func이 던지는 예외에 것을 알길이 없어서 예외 명세에 위반하는 위험한 상황으로 갈수 있다.
          * 세번째로 당신은 "the system"이 아마 던지는 예외를 핸들링해서 unexcepted의 호출을 피할수 있다. 이러한 예외는 많은 부분이 new와 new[]시 메모리 할당 예외에서 bad_alloc이 발생하여 발생한다. 만약 당신이 new를 어떤 함수에서 쓴다면 우연이라도 bad_alloc 예외를 만날수 있는 가능성을 내포하는 셈이다.
         이렇게 하면 unexpected예외는 convertUnexpected를 호출한다. 즉, 새로운 UnexpectedException 객체로 예외가 교체되었다. 하지만 제공되는 예외 명세에서 unexpected를 방지할려면 UnexpectedException 예외를 포함해야 한다. 예외를 객체로 던졌기에.. (만약 예외 명세에 UnexpectedException을 넣지 않았다면 unexpected가 교체되지 않은 것처럼 terminate가 불릴것이다.)
         이제 당신은 예외 명세가 많은 문제를 가지고 있을수 있음을 이해 할것이다. 컴파일러는 그들의 부분적인 쓰임새를 검사해서 템플릿에서 문제를 발생할 소지를 않으며, 컴파일러는 의외로 규칙위반을 하기 쉽고, 컴파일러가 제대로 되지 않으면 프로그램을 불시에 멈추어 지도록 유도할것이다. 예외 명세 역시 또다른 문제를 안고 있는데, 예외명세는 높은 수준의 호출자가 예외 발생을 대비할때도 unexpected로의 결과물을 만들어 낸다.
         Session의 파괴자는 logDestruction을 호출한다. 하지만 명시작은 어떠한 예외도 해당 logDestruction에서 던지지 못하도록 막아놓았다. 한번 logDestuction이 실패할때 불리는 함수들에 대하여 생각해 보자. 이것은 아마 일어나지 않을 것이다. 우리가 생각한대로이건 상당히 예외 명세의 규정 위반으로 인도하는 코드이다. 이런 예측할수 없는 예외가 logDestruction으로 부터 퍼질때 unexpected가 풀릴 것이다. 기본적으로 그것은 프로그램을 멈춘다. 이 예제는 그것의 수정 버전이지만, 그런 수행을 Session 파괴자의 제작자가 원할까? 작성자는 ''모든 가능한 예외'' 를 잡으려고 노력한다. 그래서 그건 Session 파괴자의 catch블럭에서수행되는 것이 다다면 그건 불공평한 처사라고 보인다. 만약 logDestruction이 아무런 예외 명세를 하지 않는다면, ''I'm-willing-to-catch-it-if-you'll-just-give-me-a-chance'' 시나리오는 결코 일어나지 않을것이다. (이런 문제의 예방으로 unexpected의 교체에 대한 설명을 위해 언급해 두었다.)
  • MoreEffectiveC++/Techniques2of3 . . . . 19 matches
         Reference counting(이하 참조 세기, 단어가 길어 영어 혼용 하지 않음)는 같은 값으로 표현되는 수많은 객체들을 하나의 값으로 공유해서 표현하는 기술이다. 참조 세기는 두가지의 일반적인 동기로 제안되었는데, '''첫번째'''로 heap 객체들을 수용하기 위한 기록의 단순화를 위해서 이다. 하나의 객체가 만들어 지는데, new가 호출되고 이것은 delete가 불리기 전까지 메모리를 차지한다. 참조 세기는 같은 자료들의 중복된 객체들을 하나로 공유하여, new와 delete를 호출하는 스트레스를 줄이고, 메모리에 객체가 등록되어 유지되는 비용도 줄일수 있다. '''두번째'''의 동기는 그냥 일반적인 생각에서 나왔다. 중복된 자료를 여러 객체가 공유하여, 비용 절약 뿐아니라, 생성, 파괴의 과정의 생략으로 프로그램 수행 속도까지 높이고자 하는 목적이다.
         다음에 구현해야할 사항은 할당(assignment)관련한 구현 즉 operator= 이다. 복사 생성자(copy constructor)를 호출이 아닌 할당은 다음과 같이 선언되고,
         그리고 이 shareable인자는 non-const operator[]가 호출될때 false로 변경되어서 이후, 해당 자료의 공유를 금지한다.
         RCObject는 참조 카운터를 보관하고, 카운터의 증감을 해당 클래스의 멤버 함수로 지원한다. 하지만 이건 유도되는 다른 클래스에 의하여, 손수 코딩이 되어야 한다. 즉, 위의 경우라면, StirngValue 클래스에서 addReference, removeReference 를 호출하면서, 일일이 코딩해 주어야 한다. 이것은 재사용 클래스로서 보기 않좋은데, 이것을 어떻게 자동화 할수는 없을까? C++는 이런 재사용을 지원할수 있을까.
         이러한 구현은 쉽고, 당신이 사용하고자 하는 많은 차원에서 일반화 시키기도 용이하다. 하지만 결점이 있는데, Array2D 객체는 built-in 배열같이 보이지 않는다는 점이다. 사실 위의, 각 data의 인자들에 대하여 (3,4)과 같은 접근 방법은 함수 호출과 같은 모습을 하고 있다.
         여기에서 data[3]은 Array1D를 이야기 하는 것이고, operator[]는 두번째 차원에 위치 (3,6)에 있는 float를 호출한다.
         Array2D의 클라이언트에 의해 사용되어지는 개념적인 모델의 부제로, Array1D 각각의 객체는 1차원 배열을 의미한다. 다른 객체를 위해 존재하는 객체들을 보통 '''''proxy object'''''라고 불리이고, oproxy객체는 proxy class에 의해 호출된다. proxy 클래스 or 의 인스턴스는 일차원 배열의 근간이 되는데, 개념적으로 존재하지 않은다. (proxy 객체를 위한 기술과 클래스는 전체에서 동떨어진 모습이다.; 그러한 클래스의 객체 역시 때로 ''surrogate''(대리자) 라고도 불릴 것이다.
         operator[] 는 각기 다른 목적으로 호출될수 있음을 유의하라: 문자를 읽거나 혹은 문자를 쓰거나, 읽기는 rvalue의 형태로 쓰여지도록 알려져 있다.; 그럼 쓰기는 lvalue형태(r은 right hand value, l은 left 이하 같음) 일반적으로 lvalue의 의미는 객체에서 그러한 객체의 수정을 의미하며, rvalue는 수정을 할수 없는 것을 의미한다.
         이러한 상태, 즉 perator[]에서 lvalue와 rvalue를 구분해야만 한다. 왜냐하면 참조세기가 적용된 자료구조의 경우에 읽기는 쓰기에 비하여 훨씬 적은 비용을 소모하기 때문이다. Item 29에서 참조세기 객체의 쓰기는 아마 전체 자료구조의 복사를 유도하지만, 읽기는 간단한 값의 반환을 의미한다고 설명했다. 불행히도, operator[]의 내부에서, 이들의 호출 목적을 구분할 방법은 없다. operator[]는 lvalue와 rvalue의 쓰임의 차이를 구분할수 없다.
         cout << s1[5]; // non-const operator[] 호출 왜냐하면
         s2[5] = 'x'; // 역시 non-const operator[] 호출: s2는 non-const이다.
         s1[3] = s2[8]; // 둘다 non-const operator[] 호출 왜냐하면 s1,s2모두
         Item 29에서 우리는 operator[]를 쓰기를 위해서 재 디자인했다. 아마 이걸 쉽게 포기할수는 없을 꺼다.(작성자주:얼마나 고생하면서 봤는데, 바꾸기 싫지.) Item 29의 디자인은 lvalue와 rvalue의 사용을 구분하는 것이 아니라, operator[]를 호출하면 무조건 쓰기로 취급해 버리는 것이다.
         예상되는 대로 operator[]의 목표인 간단한 할당(assignment)은 성공하지만, left-hand의 operator[]에서 operator+=이니 operator-=를 호출하는건 실패한다. 왜냐하면 operator[]가 반환하는 것은 프록시 객체 이기 떄문이다. 비슷한 경우에 존재하는 모든 연산자가 실패한다. operator*=, operator/=, operator<<=, operator-= 등 말이다. 만약 이런 수행을 원한다면 이러한 함수를 모두 선언해주어야 하는데, 이는 너무 일이 많다 그리고 아마 원하지도 않을 것이다. 추가한들 추가하지 않은들 둘다 괴로운 일이다.
         관계있는 문제로 프록시를 통한 실제 겍체의 호출에서 일어날수 있는데, 할수 없는것에 관한 모호성이다. 예를들어서, 유리수 배열을 참조세기로 구현했다고 해보자. 이것을 Rational 클래스로 정의하고 Array 템플릿을 사용한다. 코드는 다음과 같다.
         마지막 프록시가 실패하는 진짜 객체를 교체하지 못하는 상황은 암시적(implicit) 형변환에서 기인한다. 프록시 객체는 암시적(implicit)으로 진짜 객체로 형변환할때 user-defined 형변환 함수가 불린다. 예를들어서 CharProxy는 char로 operator char을 호출해서 변화한다. Item 5의 설명을 보면 컴파일러는 user-defined 형변환 함수를 반응하는 인자로의 필요성이 있는 부분에서 해당 연산을 호출한다고 한다. 결국 함수 호출은 프록시가 전달될때 실패하면 실제 객체를 넘기는 것을 성공시켜서 가능한 것이다. 예를들어서 TVStation리하는 클래스에 watchTV 함수가 있다고 한다면:
  • MoreEffectiveC++/Techniques1of3 . . . . 18 matches
         혹은 약간 수를 써서 readComponent를 호출하는 식으로 바꾼다면
         보다시피 클래스의 가상 복사 생성자는 실제 복사 생성자를 호출한다. 그러므로 "복사" 의미로는 일반 복사 생성자와 수행 기능이 같다 하지만 다른 점은 만들어진 객체마다 제각각의 알맞는 복사 생성자를 만든다는 점이 다르다. 이런 clone이 NewsLetter 복사 생성자를 만들때 NLComponent들을 복사하는데 기여를 한다. 어떻게 더 쉬운 작업이 되는지 다음 예제를 보면 이해 할수 있을 것이다.
          static Printer& thePrinter(); // 외부에서 호출 가능하도록 static으로 선언하고
         그리고 thePrinter를 호출하려면 이제는 이렇게 해야 한다.
         '''첫번째'''로 만들어지는 객체의 위치이다. 위의 제시된 두가지의 방법에서, Printer 정적(staitc) 객체가 하나는 friend로 클래스의 제어권을 획득한 함수 내부에 있고, 또 하나는 클래스 멤버 메소드 내부에 있다. 함수에 있는 경우에는 정적(static) 객체는 항상 만들어져 있다. 이 의미는 해당 코드의 프로그램이 시작될때 부터 아예 객체가 만들어 진다는 의미이다. 즉, 한번도 그 객체를 사용하지 않아도, 객체는 이미 만들어져 비용을 지출하게 한다. 반면에, 함수 멤버 메소드 내부에 정적(static)객체를 만들 후자의 경우에는 객체를 만드는 역할을 하는 메소드인 Printer::thePrinter 가 제일 처음 호출될때 객체가 생성된다. 이것은 C++에서 "사용하지 않는 객체에 대한 비용은 지불하지 않는다."의 설계 다소 복잡한 이념에 근간을 둔 개념이다. 그리고 이러한 복잡한 개념은 당신을 해깔리게 만든다.
         다음과 같은 코드의 함수는 매우 짧다. 이런 짧은 함수는 함수보다 inline 시켜서 속도를 높이는 것이 더 효과적이다. 하지만 그럴수가 없다. 왜 그런가 하면, inline의 의미는 정확히 해당 함수가 쓰이는 코드를 현재 함수의 몸체로 교체해 버리는 역할이다. 그런게 이렇게 할경우, 위와 같은 함수는 static객체의 처리에서 의문이 생긴다. 해당 함수가 호출된 곳을 위와 같은 함수 몸체로 교체하면, 각 교체 부분은 전부 독립적인 static 인자를 부여 받는 셈이 되어 버린다. 그래서 정적 인자를 쓴 함수는 inline을 시키지 못하며, 이런 정적 인자의 사용에 따라 일어나는 의문을 internal linkage를 가진 문제 라고 한다. DeleteMe) 날림 요약 수정 필요
         우선 객체를 Heap영역 상에서만 생성되고 사용하는 객체로 제한하는 것에 관해서 생각해 보자. Heap영역에 자리를 차지하는 객체는 모두 new를 호출해서 한자리씩 하니, 뭐, 간단히 new를 막아 버리면 되는것이다. 그렇다면 반대로 Heap영역이 아닌 객체들은 모두 new를 호출하지 않고, 자동으로 묵시적 생성되고, 묵시적 파괴되어 진다는 의미가 됙ㅆ다.
         그렇자민 아마 조금 다른 방법의 접근을 할수 있다. 바로 Heap영역에 올라가는 객체는 항상 new를 호출하는것, 그리고 이 new의 호출은 new operator와 operator new와의 상호 작용에서 작업이 이루어 지는 것이다. 자세한 내용은 Item 8을 참고하고, 다음과 같이 UPNumber를 고쳐서 유도되는 객체들 마져 제한을 걸수 있다.
         명백히 *pa는 heap상에 위치한 객체이다. 또 명백하게, pa->value의 포인터 역시 delete로 지울수 없다. 왜냐하면 이녀석이 new를 호출해서 만든것이 아니기 떄문이다.
          void *p = getMemory(size); // 메모리를 할당하는 어떤 함수를 호출한다.
         설정될 시나리오는 분산 시스템상, 분산 DB에서, local 에 있는 객체와, remote에 있는 객체를 다루기 이다. 클라이언트 입장에서는 둘을 다루는 방법이 이원화 되어 있어서, 해당 객체의 프로시저 호출에 일관성이 없을 경우 프로그래밍 환경이 불편하고, 명시성이 떨어지는 등 여러 불리한 점이 있다. 그래서 아예 양쪽의 객체에 사용법에 대한 일관성을 가지고 싶어 한다. 이를 해결 하기 위해서 스마트 포인터로, 해당 객체를 둘러싸서, 프로시저의 일관된 사용 방법을 제공 받고자 한다. 다음은 그것을 구현한 코드들이다.:
         auto_ptr<TreeNode> ptn2 = ptn1; // 복사 생성자를 호출했다. 어떤 일이 일어날까?
         ptn3 = ptn2; // operator=를 호출했다. 어떤 일이 일어날까?
         이렇게 제기되는 문제의 대안으로 가리키고 있는 객체에 대하여 복사를 수행한뒤에 가리키도록 만들수 있다. 하지만 이런 구현 상태는 자칫, 많은 copy, assign의 남발시에 new와 delete의 다량의 호출로, 속도 저하와, "같은 것을 같은 것을 가리키고 있다." 라는 의미로 쓴 프로그래머에게 의미를 호도 시켜버릴수 있다.
         이렇게 복사 생성자(copy constructor)가 불리거나 할당 연산자(assignment operator)를 호출할 경우 소유권(ownership)을 이양한다. 만약 이런 작업이 실패하면, 결코 객체는 지워질수가 없다. 하지만 이런 방식은 치명적인 결과를 불러 올수 있다.
         이 함수의 반환 형은 참조(reference)이다. 객체를 반환하면 어떻게 되는가? 난리도 아닐것이다. 객체의 반환은 객체가 복사로 전달시에 생성, 삭제에서의 비효율은 물론, Item 13에 제시되는 slicing을 발생할 가능성이 있다. 또 Item 13에서도 계속 다룬 가상 함수를 호출할때 역시 객체를 통한 반환은 문제를 발생시킨다. Reference로 전달해라, 이것의 효율성에 관해서는 이미 다루었기에 더 말하지 않는다.
  • AcceleratedC++/Chapter13 . . . . 15 matches
          Core::grade()를 사용하지 않고 grade()를 사용하게 되면 Grade:grade()를 재귀적으로 호출하여 어떤 결과를 리턴할지 예상하지 못한다.
          || * 전체 객체에 대한 공간을 할당 [[HTML(<BR/>)]] * 기본 클래스 생성자 호출, 기본클래스 공간 초기화 [[HTML(<BR/>)]] * 생성자의 초기설정자''( ): { 사이에 존재하는 것들 )''를 이용해서 파생클래스의 멤버 초기화 [[HTML(<BR/>)]] * 파생 클래스의 생성자의 본체를 실행한다. ||
         비록 함수가 요구하는 인자값은 Core 클래스 이지만 Grad는 Core를 기반으로해서 파생된 클래스이기 때문에 이 경우 name();를 호출하게 되면 g 객체의 Core::name() 부분이 호출된다.
          만약 위 함수에 인자로 전달된 객체가 Grad객체라면 그 객체에서 호출되는 grade는 Core::grade() 이어서는 안된다. 그렇게 호출될 경우 논문 점수가 적용되지 않은 성적를 리턴하기 때문이다. 따라서 Grad::grade() 의 함수를 호출해야 할 것이다.
          virtual 키워드로 지정된 함수는 실제로 함수가 호출될때 그 객체의 이름 범위에 존재하는 함수를 호출하는 것이 가능하다.
          상기의 경우 Grad 객체를 인자로 전달할 경우 Grad객체의 Core객체의 요소만 복사되어 함수의 인자로 전달되기 때문에 Core::grade()가 호출되어서 '''정적바인딩(static binding)'''이 수행된다.
          만약 일반형의 변수로 virtual함수를 호출하면 객체가 항상 한가지 타입으로만 존재하기 때문에 정적바인딩이 된다. 그러나 포인터, 참조형의 경우 이렇게 할때에는 동적바인딩으로 동작하게 된다. 포인터의 형과 실제 포인터가 가리키는 데이터형이 다른일이 생기기 때문이다. 따라서 이 경우 virtual 멤버함수는 '''런타임에 동적으로 바인딩''' 된다.
          기본 타입에 대한 포인터나 레퍼런스가 필요한 곳에 파생 타입을 사용할 수 있다는 개념. 하나의 타입을 통해서 여러 함수들 중 하나를 선택하여 호출할 수 있다.
          상기와 같은 구조에서는 students[i]의 타입이 Core* 이기 때문에 메모리 해제시에 Core버전의 소멸자가 호출되고 Grad 부분은 해제되지 않는다.
          Student_info 클래스에서 Grad::clone()를 직접적으로 호출하는 경우가 없기 때문에 friend로 선언하지 않아도 무관하다.
          r.Core::regrade(100); // 작동. 범위 연산자를 이용해서 명시적으로 호출하는 것은 허용한다.
  • 코바용어정리 . . . . 15 matches
         클라이언트의 반대쪽에는 구현 객체라고 알려진 실제 객체가 있다. '구현 객체(Object Implementation)'는 실제 상태(state)와 객체의 반응 양상(behavior)을 규정하며 다양한 방식으로 구성될 수 있다. 구현 객체는 객체의 메소드와 객체에 대한 활성화 및 비활성화 프로시저를 정의한다. 구현 객체는 객체 어댑터의 도움을 받아 ORB와 상호 작용한다. 객체 어댑터는 구현 객체를 특정하게 사용하는 데에 편리하도록 ORB 서비스에 대한 인터페이스를 제공하게 된다. 구현 객체는 ORB와 상호 작용하여 그 정체를 확립하고 새로운 객체를 생성하며 ORB에 따르는 서비스를 획득할 수 있도록 한다. 새로운 객체가 생성되면 ORB에게 통보되고 이 객체의 구현이 어디에 위치하는가를 알게 된다. 호출이 발생하면 ORB, 객체 어댑터, 스켈레톤은 구현의 적절한 메소드에 대한 호출이 되도록 만들어야 한다.
         의 인터페이스 타입에 대해 스텁에 대한 프로그래밍 인터페이스를 필요로 한다. 보통 스텁은 OMG-IDL로 정의되어 있는 객체 오퍼레이션에 대한 액세를 하게 해주는데, 일단 프로그래머가 OMG-IDL 및 특정 프로그래밍 언어에 대한 언어 매핑에 친숙해지면 손쉽게 예상이 가능한 방식으로 액세르를 하게 해준다. 해당 스텁은 ORB 코어에 전용이며 최적화된 인터페이스를 사용해서 나머지 ORB들을 호출하게 될 것이다. 만약 여러 개의 ORB를 사용하게 된다면 각각의 스텁은 제 각기 해당하는 ORB를 호출하게 될 것이다. 이 경우에 ORB와 언어 맵핑은 공조하여 각각의 스텁이 특정 객체 레퍼런스와 제대로 연결될 수 있도록 해야 할 것이다.
         == 동적 호출 인터페이스(DII : Dynamic Invocation Interface) ==
         클라이언트가 호출될 객체와 수행할 오퍼레이션을 지정하고자 할 때, 특정 객체 A의 특정 오퍼레이션을 지정하는 대신 객체 호출을 동적으로 생성하도록 허용하는 인터페이스를 이용할 수 있다. 이러한 경우 클라이언트 코드에서는 수행되는 오퍼레이션과 전달되는 파라미터의 타입에 대한 정보를 제공해야 한다. 이 정보는 대개 인터페이스 저장소와 같은 런타입 소스에서 얻어진다. 실행 시간 중에 해당 정보를 얻은 후, 클라이언트 코드는 이른바 동적 호출 인터페이스(DII)를 이용해서 동적으로 호출을 할 수 있게 된다.
         각각의 언어 매핑에 대해(아마도 객체 어댑터에의 의존하게 되겠지만) 각각의 타입의 객체를 구현하도록 해주는 메소드에 대한 인터페이스가 존재할 것이다. 이 인터페이스는 일반적으로 업콜(up-call) 인터페이스일 것이다. 구현 객체의 개발자는 그 인터페이스에 따라 루틴을 작성하게 되고 ORB는 스켈레톤을 통해서 그 루틴을 호출하게 될 것이다. 그러나 스켈레톤의 존재가 그에 사응하는 클라이언트 스텁의 조재를 의미하지는 않는다는 것이다. 이말은 클라이언트가 DII를 통해서 리퀘스트를 만들 수도 있다는 것이다. 또한, 어떤 언어 맵핑은 스켈레톤을 사용하지 않는데, 이것은 Smalltalk에시는 대체적으로 맞는 말이다.
         동적 스켈레톤 인터페이스는 IDL에 기초하지 않는 스켈레톤/스텁을 가진 객체의 메소드 호출을 처리해야 하는 서버에 대해 런타임 바인딩 메커니즘을 제공한다. 동적 스켈레톤은 수신된 메시지의 파라미터값을 참조하여 어떤 객체가 호출되었는지 어떤 메소드가 호출되었는지를 알게 된다. 이것은 일반적으로 컴파일된 스켈레톤을 사용하는 것과는 비교되는데 이러한 스켈레톤에서는 메소드의 구현이 IDL로 정의된다. 구현 코드는 모든 오퍼레이션 파라미터에 대한 상세한 설명을 ORB에 제공해야 하며, ORB는 오퍼레이션을 수행할 때 사용되는 입력 파라미터값을 제공한다. 오퍼레이션이 수행된 후, 구현 코드는 출력 파라미터 또는 익셉션을 ORB에게 넘겨준다. 동적 스켈레톤 인터페이스의 특성은 프로그래밍 언어 맵핑에 따라 또는 객체 어댑터에 따라 실질적으로 달라질 수 있지만, 일반적으로는 업콜 인터페이스이다. 동적 스켈레톤은 클라이언트 스텁 또는 DII를 통해서 호출될 수 있다. 이 두 가지 방식의 클라이너트 리퀘스트 생성 인터페이스는 동일한 결과를 제공한다.
         ORB 인터페이스는 애플리케이션에 중요한 지역 서비스에 대한 API들로 구성되어 있지 않다. 이것은 곧바로 ORB로 가는 인터페이스이고 모든 ORB들에 대해 동일하다.ORB 인터페이스는 객체 어댑터 또는 객체 인터페이스에 의존하지 않는다. 대부분의 ORB의 기능이 객체 어댑터, 스텁, 스켈레톤 또는 동적 호출 등을 통해서 제공되므로 몇몇 오퍼레이션만이 모든 객체들에 대해 공통이다. 공통 오퍼레이션에는 get_interface와 get_implementation 같은 함수가 포함되어 있는데, 이것들은 임의의 객체 레퍼런스에 작용하며 각각 인터페이스 저장소 객체와 구현 저장소 객체를 얻는 데 사용된다.
  • JavaNetworkProgramming . . . . 14 matches
          execution = null; //쓰레드가 크리티컬 섹션을 수행하는 도중 이 메소드가 호출되는 경우,중요한 데이터에 다른 쓰레드가 영영 접근할수 없는
          *Thread 통지(notification)메소드 : 주의해야 할 점은, 이 메소드들 호출하는 쓰레들이 반드시 synchronized 블록으로 동기화 되어야 한다는 점이다.
          *wait() : notify() 메소드를 호출할 때까지 블록킹된다.
          *notifyAll() : 메소드가 호출된 객체에서 대기하고 있는 모든 쓰레드들을 깨운다.
          out.close(); //close가 호출되지 않으면 FileOutputStream에 가비지 콜렉션이 일어날 때에 파일과 하부의 FileDescriptor가 자동으로 닫힌다.
          this(file.getPath()); //역시 자신의 생성자를 호출
          *FilterWriter : 모든 문자 스트림 필터의 스퍼클래스로 다른 Writer 객체에 연결되어서 모든 호출 연결된 스트림으로 전달한다.
          *FilterReader : 모든 Reader 문자 스트림 필터의 수퍼클래스로, 다른 Reader객체와 연결하여 모든 메소드의 호출을 연결된 스트림으로 전돨한다.
          *BufferedWriter : 연결된 스트림에 출력 버퍼링 기능을 제공한다. 모든데이터는 버퍼가 가득 찾거나 flush() 메소드가 호출되거나 close() 메소드가 호출될 때까지 내부 버퍼에 저장되었다가 여러 문자를 한꺼번에 출력하는 write()메소드의 호출을 통해 연결된 스트림으로 출력된다.
          enableReplaceObject(true); //이메소드를 호출해야만 replaceObject를 호출할수있음 보안문제
          enableResolveObject(true); //resolveObject()호출 가능하게한다.
  • Java Study2003/첫번째과제/장창재 . . . . 13 matches
         C와 같이 다른 언어로 작성된 함수를 직접 호출합니다.
         C언어를 이용하여 C 프로그램을 작성한다면 반드시 main이라는 시작 함수를 정의해 주어야 하고, 윈도우 응용프로그램을 작성한다고 하면 WinMain이라는 함수를 꼭 작성해 주어야 하지요. 이러한 것을 규약(protocol)이라 합니다. 마찬가지로, 자바 언어를 이용하여 여러 가지 종류의 자바 프로그램을 작성할 수 있는데, 이 때 각 자바 프로그램의 종류에 따라 해당 규약이 서로 다릅니다. 이렇듯 자바를 이용하여 자바 프로그램을 작성한다는 것은 각 자바 프로그램에서 제시하고 있는 규약을 지켜 프로그램을 작성한다는 것입니다. 자바 언어를 이용하여 작성할 수 있는 자바 프로그램의 종류를 살펴보면 다음과 같습니다.
         <APPLET>~</APPLET> 태그를 이용하여 HTML 페이지 내에 포함되어, 자바 호환 웹 브라우저에 의해서 실행되도록 작성된 자바 프로그램입니다. 다시 말해서, 여러분의 홈 페이지 내에 삽입되어 자바 호환 웹 브라우저에 의해 실행되도록 규약에 맞추어 작성된 자바 프로그램을 말하는 것입니다. 다음에 나오는 그림은 자바 애플릿의 실행 과정을 자세히 보여주고 있습니다.
         다른 자바 프로그램에 의해 삽입(import)되어 사용될 수 있도록 작성된 자바 프로그램입니다. 이러한 자바 패키지는 기존의 프로그래밍 언어에서 사용하던 라이브러리 또는 운영체제에서 제공해 주는 API 등과 같다고 볼 수 있습니다. 자바 패키지 역시 해당 규약을 갖겠지요. 자바에서는 기본적으로 압축 파일의 형태로 'casses.zip"이라는 자바 패키지가 제공되고 있고, 압축 파일 내에는 디렉토리 단위로 패키지가 포함되어 있습니다. 다음에 나오는 그림은 JDK 1.2.2 에서 제공되는 패키지를 보여주고 있습니다.
         따라서, 여러분은 하나의 자바 프로그램을 작성할 때, 위에 나열된 하나의 규약에 맞게 자바 프로그램을 작성할 수도 있지만, 하나의 자바 프로그램이 위의 규약들을 두 개 이상 만족하도록 작성할 수도 있습니다.
         이렇게 두 개 이상의 자바 프로그램 규약을 만족시키는 자바 프로그램은 여러 자바 프로그램에 속하게 됩니다. 예를 들어, 하나의 자바 프로그램을 작성했는데, 이 자바 프로그램은 자바 애플리케이션을 위한 규약을 만족시켜 주고 자바 애플릿을 위한 규약도 만족시켜 준다면, 이 자바 프로그램은 JDK와 함께 제공되는 자바 가상머신에 의해 실행되는 자바 애플리케이션으로서 독립적으로 실행될 수도 있고, 자바 호환 웹 브라우저에 내장된 자바 가상머신에 의해 자바 애플릿으로 실행될 수도 있다는 것입니다. 이렇게 자바 언어를 이용하여 여러 규약에 맞는 자바 프로그램을 작성할 수 있지만, 하나의 자바 프로그램이 굳이 두 개 이상의 규약을 모두 만족시켜주도록 자바 프로그램을 작성하는 경우는 자바 애플리케이션과 자바 애플릿의 경우를 제외하고는 거의 없습니다.
  • 작은자바이야기 . . . . 13 matches
          * JNI라는 기법을 사용해 네이티브 라이브러리를 연결하여 함수를 호출할 수 있음을 배웠습니다.
          * 생성 메소드를 호출하는 인스턴스의 타입, 메소드에 들어가는 인자의 두 가지가 새로 생성되는 인스턴스에 영향을 주는 경우 abstract factory
          * template method 패턴이 사용됐다. protected로 선언된 service method가 template method에 해당되는데 abstract가 아닌 이유는 기본 구현을 주고 원하는 호출에 대해 오버라이드를 해서 사용하기 위함이다.
          * servlet은 thread per request 구조로 하나의 servlet 객체가 여러개의 스레드에서 호출되는 구조.
          * Java에서 다른 언어(C언어)로 된 라이브러리를 동적으로 호출해서 사용할 수 있도록 해 주는 방법.
          * .java 파일에는 클래스 내에 native modifier를 붙인 메소드를 작성하고, .c, .cpp 파일에는 Java에서 호출될 함수의 구현을 작성한다. 이후 System.loadLibrary(...) 함수를 이용해서 .dll 파일(Windows의 경우) 또는 .so(shared object) 파일(Linux의 경우)을 동적으로 로드한다.
          * .cpp 파일로 작성했을 때 사용하는 extern "C"는 함수 호출 규약(__cdecl, __stdcall)과 관련된 부분이다. extern "C"를 적어주는 것으로 __cdecl로 함수를 호출하도록 한다.
          * invokespecial - vtable lookup을 하지 않고 메소드를 호출하는 경우. 어떤 메소드를 호출해야 하는지 정해져 있는 경우에 사용된다. new, private method, super 등.
          * invokestatic - static 메소드 호출. 첫 인자로 this를 넣어주지 않는다.
          * invokeinterface - virtual과 거의 같다. interface의 메소드를 호출하는 경우에 사용한다.
  • MoreEffectiveC++/Operator . . . . 12 matches
         컴파일러 단에서 a생성자인 Array( ArraySize size) 에서 ArraySize 로의 single-argument constructor를 호출하기 때문에 선언이 가능하지만
         string 객체가 필요로 하는 메모리 만큼이 할당된다. 하지만 위의 의미처럼 malloc, operator new는 생성자를 호출하지는 앖는다. 생성자의 호출은 new operator 몫이다.
         해당 코드 두번째 부분의 생성자 호출을 눈여겨 봐라.
         당신은 생성자를 직접 호출하기를 원할때가 있을 것이다. 하지만 생성자는 객체(object)를 초기화 시키고, 객제(object)는 오직 처음 주어지는 단 한번의 값으로 초기화 되어 질수있기 때문에 (예-const 인수들 초기화에 초기화 리스트를 쓰는 경우) 생성자를 이미 존재하고 있는 객체에 호출한다는건 생각의 여지가 없을 것이다.
         해당 함수(construcWidgetInBuffer())는 버퍼에 만들어진 Widget 객체의 포인터를 반환하여 준다. 이렇게 호출할 경우 객체를 임의 위치에 할당할수 있는 능력 때문에 shared memory나 memory-mapped I/O 구현에 용이하다 constructorWidget에 보이는건 바로
         이 문인데 , 아마 처음 보기에 생소할 것이다. 자세히 뜯어 보면, (buffer)에 의해서 암시적으로 new는 operator new로 호출되어 진다. 덧붙여, 아래의 void*는 메모리 상의 위치를 size_t는 메모리상 객체가 차지하는 영역이다. 자, 위와 비교해 보라 이 operator는 new를 overload한 버전이다.
         이거 간단히 보이지만 placement new의 전부이다. operator new의 역할은 해당 객체를 위한 메모리를 찾고(할당), 해당 포인터의 반환이고 placement new의 경우에는 호출자가 이미 메모리를 확보하였고, 단순히 포인터 반환만 해준다. 모든 placement new가 반드시 이런 pointer의 전달 역할을 한다. 그리고 size_t 인자가 아무런 이름이 없어도 반항 안한다. 자세한건 Item 6을 보면 이해가 갈것이다.
         the '''new''' operator : heap 메모리 확보와 생성자 호출 동시에[[BR]]
         위의 코드는 C++상에서 malloc 과 free 를 호출 것과 동일한 역할을 한다.
          pw->~Widget(); // 먼저 임의로 파괴자를 호출한다. 이렇게 하면 pw과 관련된 자원을 반환할것이고.
  • TermProject/재니 . . . . 11 matches
          if (select == 1) menu1(); // 각 선택에 맞게 함수를 호출
          else error(); // 잘못 입력하였을 경우 에러메시지를 출력하는 함수 호출
          sub_menu(); // 서브메뉴 호출
          if (select >= 1 && select <= 3) // 서브메뉴의 선택에 따라 화면에 출력하는 함수를 호출
          sub_menu(); // 서브메뉴 호출
          sort(i, j); // 정렬 함수를 호출
          prt_select(); // 선택된 서브메뉴에 따라 출력하는 함수를 호출
          avr(); // 평균 산출 함수를 호출
          avr(); // 평균 산출 함수를 호출
          for (int j = 0 ; j < i ; j++) // 정렬 함수를 호출하여 정렬함
          error(); // 잘못 입력하였을 경우 에러메시지를 출력하는 함수 호출
  • JavaStudy2003/두번째과제/노수민 . . . . 9 matches
         객체 생성자는 new 연산자를 이용하여 객체를 생성할 때도 호출된다.
          * 객체가 생성될 때 자동호출, 객체의 변수초기화, 메모리 할당들의 작업을 함
          * new 연산자로 객체를 생성할때 호출, 메모리를 할당하고 객체 생성자 호출
         다른 객체 생성자 호출; ß 반드시 첫번째 줄에서
         * 객체생성자 내에서 다른 생성자 호출
          * this : 클래스 내의 객체 생성자에서 다른 객체 생성자를 호출
          * super : 하위클래스의 객체 생성자에서 상위클래스의 객체 생성자를 호출
          * 상위클래스의 생성자를 호출
  • AcceleratedC++/Chapter4 . . . . 7 matches
          * 함수를 호출할때에는 함수를 만들때 주어졌던 parameter lists를 충족시키는 값들을 넣어줘야 한다. 물론 순서도 맞춰줘야 한다. arguments라고도 한다. arguments는 식이 될수도 있다. 그 뒤에 함수로 넘어간 parameter들은 함수 내에서 지역 변수(함수가 끝나면 소멸되는)처럼 작동하게 된다. 즉 그 값들을 복사하게 되는 것이다. 이를 call by value라 한다.
          * 또한, 아까 함수 호출하면서 parameter로 넘겨줄때에는 그 값을 복사를 한다고 했다. 저렇게 함수를 호출함으로써, 원래 vector를 손상시키지 않고, 복사본 vector에서 sort를 해서 작업을 처리해 줄수가 있다. 비록 시간이 좀 더 걸리긴 하지만..
          // empty()메소드를 호출하는 것이 더 효율적이라고 하더군요.
          * grade() function : 우리는 아까 grade라는 함수를 만들었었다. 그런데 이번에 이름은 같으면서 parameter는 조금 다른 grade()를 또 만들었다. 이런게 가능한가? 가능하다. 이러한 것을 함수의 overloading이라고 한다. 함수 호출할때 어떤게 호출될까는 따라가는 parameter lists에 의해 결정된다.
         read_hw(cin, homework); // 호출
  • AcceleratedC++/Chapter9 . . . . 7 matches
          * s:Student_info 라면 멤버함수를 호출하기 위해서는 s.read(cin), s.grade() 와 같이 함수를 사용하면서 그 함수가 속해있는 객체를 지정해야함. 암묵적으로 특정객체가 그 함수의 인자로 전달되어 그 객체의 데이터로 접근이 가능하게 된다.
          ::를 사용함으로써 호출되는 grade를 객체의 멤버함수가 아니라 전역 grade의 형으로 사용하는 것이 가능하다.
          * const 객체에 대해서는 const 멤버함수가 아닌 함수는 호출 할 수 없다.
          상기와 같은 방식으로 통해서 grade를 호출하기 전에 객체의 유효성을 검사한다면 에러를 없애는 것이 가능하다.
          헤더파일은 단지 컴파일러가 컴파일을 할때 이런 함수가 존재한다고 가정만 하고, 실제로 그 함수의 코드가 존재하는 것을 확인 할 수 잇는 것은 모든 관련 오브젝트 파일을 링크한뒤에 호출할때 없다는 것을 확인할 수 밖엔 없다.'''
          객체가 어떤게 초기화되는지를 정의하는 특별한 멤버 함수이다. 명시적인 호출을 지원하지 않으며, 오로지 객체가 생성될 때에만 실행된다.
         Student_info::Student_info():midterm(0). final(0) {} // n, homework 의 경우 STL에서 제공되는 디폴트 생성자가 재귀적으로 호출
  • BigBang . . . . 7 matches
          * return에는 중요한 특성이 있는데 이게 호출되면 지역변수를 정리한다.
          * C/C++의 함수 호출 방법(Calling Convention)
          * 인스턴스는 NULL를 가리키지만, 실제로 실행될 때는 hello 함수만을 호출하기 때문이다. (문장 설명이 부족한데?)
          * stack이나 heap에서 데이터를 free 할 때, 실제로 포인터만 이동이 된다. 그래서 실제로는 데이터가 메모리에 남아있게 된다(기존의 값을 초기화화 할 필요없이 할당 플래그만 해제하면 되므로). 중간에 다른 곳에서 호출이 될 경우에 데이터가 덮어 써지는 문제가 발생할 수 있으므로, dangling pointer를 조심해야 한다.
          * 복사 생성자 - 어떤 객체의 초기화를 위해 그와 같은 타입의 객체로부터 초기화할 때 호출되는 함수.
          이유는 string은 생성자가 호출되지 않으므로(malloc에 의해서)
          * 비상수 버전과 상수 버전 - 비상수 버전에서 상수 버전을 호출;
  • HardcoreCppStudy/두번째숙제/ConstructorAndDestructor/변준원 . . . . 7 matches
         클래스의 인스턴스가 생성되었을때에 즉, 객체가 생성될때 호출됩니다.
         해당하는 함수나 메인에서 생성이될때 호출이 되죠. 이때, default 생성자와
         인수값을 갖는 여러 생성자가 함께 올 수있으며 인수값에 따라서 호출되는 생성자가 달라집니다.
         소멸자의 경우 ~Test(); 부분이 소멸자에 해당되고, 객체가 사라질때 호출되는데,
         만일 메인함수에서 객체를 생성하였다면 메인함수가 사라질때 호출이 되고,
         전역적으로 선언되어서 생성된경우는 프로그램이 종료시에 호출됩니다.
         대입연산자나 함수를 호출할때, new 연산자에 의해 생성됩니다.
  • PascalTriangle . . . . 7 matches
         == 재귀 호출을 이용한 방법 - by 인수 ==
          return pas(m-1,n-1)+pas(m-1,n); // 재귀호출
          * but.. 숫자가 조금만 커져도.. 굉장히 오래 걸립니다. 01학번 이선호군이 32행 정도를 넣어봤을때 걸린 시간은 100초가 넘었다 합니다. 재귀호출.. 될수 있으면 쓰지 맙시다.
          /* 그렇지 않은 경우 행과 열을 1씩 감소해서 재귀 호출한 값과
          행만 1 감소시켜 재귀 호출한 값을 더해서 리턴 */
          * 딱 보기에도 재귀호출보다는 복잡하죠?
          // 바꿔서 다시 호출해주는 부분이다
  • ProgrammingWithInterface . . . . 7 matches
         상위 클래스가 가지는 메소드가 적다면 모두 [오버라이딩]하는 방법이 있지만 만약 귀찮을 정도로 많은 메소드가 있다면 오랜 시간이 걸릴 것이다. 그리고 만약 상위 클래스가 수정된다면 다시 그 여파가 하위 클래스에게 전달된다. 또 다른 방법으로 함수를 오버라이딩하여 예외를 던지도록 만들어 원치않는 호출을 막을 수 있지다. 하지만 이는 컴파일 타임 에러를 런타임 에러로 바꾸는 것이다. 그리고 LSP (Liskov Sustitution Principle : "기반 클래스는 파생클래스로 대체 가능해야 한다") 원칙을 어기게 된다. 당연히 ArrayList를 상속받은 Stack은 clear 메소드를 사용할 수 있어야 한다. 그런데 예외를 던지다니 말이 되는가?
         자.. Stack과 ArrayList간의 결합도가 많이 낮아 졌다. 구현하지 않은 clear 따위 호출 되지도 않는다. 왠지 합성을 사용하는 방법이 더 나은 것 같다. 이런 말도 있다. 상속 보다는 합성을 사용하라고... 자 다시 본론으로 들어와 저 Stack을 상속하는 클래스를 만들어 보자. MonitorableStack은 Stack의 최소, 최대 크기를 기억하는 Stack이다.
         깔끔한 코드가 나왔다. 하지만 MonitorableStack은 pushMany 함수를 상속한다. MonitorableStack을 사용해 pushMany 함수를 호출하면 MonitorableStack의 입력 받은 articles의 articles.length 만큼 push가 호출된다. 하지만 지금 호출된 push 메소드는 MonitorableStack의 것이라는 점! 매번 size() 함수를 호출해 최대 크기를 갱신한다. 속도가 느려질 수도 있다. 그리고 만약 누군가 Stack의 코드를 보고 pushMany 함수의 비 효율성 때문에 Stack을 밑의 코드와 같이 수정했다면 어떻게 될 것인가???
         와!~ 예전의 Stack보다 성능은 확실히 좋아 졌을 것이다. 그런데 문제가 발생했다. 더이상 pushMany 메소드에서 push 메소드를 호출하지 않는다. 이렇게 되면 MonitorableStack은 더이상 Stack의 최대 크기를 추적하지 못하게 된다. 예기치 않은 결과이다. 상속을 사용한 구현으로 발생한 문제이다. 여기까지 글을 (책의 내용) 읽었다면, 아마 '상속을 사용하기 전에 한번 더 생각하는게 좋겠다' 라는 생각을 가슴 깊이 느꼈을 것이다. 아니면 별수 없는 일이다... :(
  • 02_C++세미나 . . . . 6 matches
         가장 대표적인 것으로 함수 호출의 전달인자에서의 활용을 알아보도록 하자.
         main 함수에서 func 함수를 호출할때는 main 함수의 a 변수의 값을
         func 함수의 a 변수로 복사해주는 형식으로 호출이 이루어진다.
         이와 같은 호출을 '''Call by value''' 라고 한다..
         아까와는 달리 main 함수에서 func 함수를 호출할때 a의 메모리 주소를 넘겨 주었다.
         이와같이 함수 호출에서 주소를 사용해 전달 인자를 넘겨주는 방법을
  • 5인용C++스터디/윈도우에그림그리기 . . . . 6 matches
         DC 핸들을 얻고 해제하는 가장 일반적인 방법은 WM_PAINT 메시지 처리 도중 BeginPaint와 EndPaint 호출을 사용하는 것이다.
         보통 프로그램이 WinMain에서 UpdateWindow를 호출할 때 발생한다. 이것은 윈도우 프로시저로 하여금 클라이언트 영역에 무엇인가를 그리게 한다.
         WM_PAINT 처리는 거의 항상 BeginPaint에 대한 호출로 시작된다.
         그리고 다음과 같이 EndPaint를 호출하여 끝난다.
         WndProc은 BeginPaint를 호출하고 난 후 GetClientRect를 호출한다.
  • C/C++어려운선언문해석하기 . . . . 6 matches
         [[ 호출 규약 (calling convetion) ]]
         같은 맥락으로 호출규약이 들어간 경우에도 똑같은 규칙을 적용합니다.
  • Gof/FactoryMethod . . . . 6 matches
         Application의 Sub 클래스는 Application상에서 추상적인 CreateDocument 수행을 재정의 하고, Document sub클래스에게 접근할수 있게 한다. Aplication의 sub클래스는 한번 구현된다. 그런 다음 그것은 Application에 알맞은 Document에 대하여 그들에 클래스가 특별히 알 필요 없이 구현할수 있다. 우리는 CreateDocument를 호출한다. 왜냐하면 객체의 생성에 대하여 관여하기 위해서 이다.
          * Product객체를 만들기위한 factory method를 호출한다.
          Ducument에제에서 Document클래스는 factory method에 해당하는, 자료를 열람하기 위한 기본 파일 다이얼로그를 생성하는 CreateFileDialog이 호출을 정의할수 있다. 그리고 Document sub클래스는 이러한 factory method를 오버 라이딩해서 만들고자 하는 application에 특화된 파일 다이얼로그를 정의할수 있다. 이러한 경우에 factory method는 추상적이지 않다. 하지만 올바른 기본 구현을 제공한다.
          클래스 식별자를 읽고서 Framework는 식별자를 Create에게 넘기면서 호출한다. Create는 적당한 클래스를 찾고, 그것을 객체의 생성에 사용한다. 마지막으로 Create는 객체의 Read 수행을 호출하여 디스크에 정보를 저장하고, 인스턴스 변수들을 초기화 한다.
         C++에서 Factory method는 항상 가상함수이고, 종종 순수 가상 함수이다. Creator의 생성자 내부에서 factory methods의 호출은 결코 좋지 못한것 일까? 그러한 factory method는 ConcreteCreator안에 존재하고, 아직 활성화 되지 않았다.
  • Gof/Visitor . . . . 6 matches
         예를든다면, visitor를 이용하지 않는 컴파일러는 컴파일러의 abstact syntax tree의 TypeCheck operation을 호출함으로서 type-check 을 수행할 것이다. 각각의 node들은 node들이 가지고 있는 TypeCheck를 호출함으로써 TypeCheck를 구현할 것이다. (앞의 class diagram 참조). 만일 visitor를 이용한다면, TypeCheckingVisior 객체를 만든 뒤, TypeCheckingVisitor 객체를 인자로 넘겨주면서 abstract syntax tree의 Accept operation을 호출할 것이다. 각각의 node들은 visitor를 도로 호출함으로써 Accept를 구현할 것이다 (예를 들어, assignment node의 경우 visitor의 VisitAssignment operation을 호출할 것이고, varible reference는 VisitVaribleReference를 호출할 것이다.) AssignmentNode 클래스의 TypeCheck operation은 이제 TypeCheckingVisitor의 VisitAssignment operation으로 대체될 것이다.
  • HardcoreCppStudy/두번째숙제/This포인터/변준원 . . . . 6 matches
         f()로 클래스 내부에선 호출이 가능한데 정확히 this->f()에서 this가 생략된 형이죠
         class A에서 class B의 내부함수를 호출하는데
         class A에서 class B의 내부함수 호출시에 this라는 인자를 넘겨줍니다
         클래스 멤버내의 함수에서 자신의 함수를 호출할때 명시적 또는 묵시적으로 사용하는
         했을때 Save함수 내에 GetA라는 함수를 호출한다고 하면 다음과 같이 사용이
         다른 클래스의 함수에서 c라는 클래스의 포인터로 GetA를 호출한다고 하면
  • 새싹교실/2012/AClass/1회차 . . . . 6 matches
         - return은 현재있는 함수에서 빠져나와 그 함수를 호출했던 곳으로 되돌아 가라는 뜻, 되돌아 가면서 그 함수를 호출했던 곳에 어떤 값을 반환하는 것,
         - 함수형 프로그래밍은 프로그래밍의 주된 구조가 함수 호출에 기반을 둔 프로그래밍을 말한다. 기존 명령형 언어로 작성한 프로그램보다 간결하고 더 추상적이며 이해하기 쉽고 형식적인 분석과 조작이 용이하다는 특징이 있다.
         - 함수내에서 자기자신을 다시 호출하는 함수
         자신이 스스로를 호출하는 함수
         - 함수 본체를 수행하는 도중에 자신을 다시 호출하는 함수
  • 2학기파이선스터디/함수 . . . . 5 matches
         == 함수의 정의와 호출 ==
         return은 계산된 값을 함수를 호출한 곳으로 돌려준다. def는 함수 객체를 생성하고 그 객체를
         add는 함수 객체를 참조하는 이름에 불과하므로 다른 이름을 이용해 함수를 호출할 수도 있다.
         인수 없이 return문 만을 사용하면 함수 호출측에 아무 값도 전달하지 않는다.
         === 튜플 인수와 사전 인수로 함수 호출하기(2.0 이상) ===
  • AcceleratedC++/Chapter11 . . . . 5 matches
          만약 멤버 함수로 연산자가 정의 되어 있다면 좌측 피연산자는 함수를 호출한 객체로 간주되고 오버로드 연산자는 인자로 우측의 피연산자만을 인자로 취한다.
          모든 멤버함수는 암묵적으로 한가지의 인자를 더 받는다. 그것은 그 함수를 호출한 객체인데, 이경우 그 객체가 const이거나 const 가 아닌 버전 2가지가 존재하는 것이 가능하기 때문에 parameter specification 이 동일하지만 오버로딩이 가능하다.
          복사 생성자는 생성자의 이름은 기타 생성자와 같으나 인자로 자신이 호출된 객체의 타입을 갖는 생성자를 의미한다.
          this는 멤버함수 안에서 유효하다. this는 멤버함수를 호출시킨 객체의 포인터를 리턴한다.
          grow 함수는 한번 호출할때 이미 워래 공간의 2배를 할당시키기 때문에 계속된 push_back로 인한 메모리 할당 오버헤드를 줄일 수 있다.
  • AspectOrientedProgramming . . . . 5 matches
          이해를 돕기 위해, 그리고 설명을 쉽게 하기 위해 예를 들어가며 AOP 개념을 설명토록 하겠다. 어플리케이션의 여러 스레드들이 하나의 데이터를 공유하는 상황을 가정해보자. 공유 데이터는 Data라는 객체(Data 클래스의 인스턴스)로 캡슐화되어 있다. 서로 다른 여러 클래스의 인스턴스들이 하나의 Data 객체를 사용하고 있으나 이 공유 데이터에 접근할 수 있는 객체는 한 번에 하나씩이어야만 한다. 그렇다면 어떤 형태이건 동기화 메커니즘이 도입되어야 할 것이다. 즉, 어떤 한 객체가 데이터를 사용중이라면 Data 객체는 잠겨(lock)져야 하며, 사용이 끝났을 때 해제(unlock)되어야 한다. 전통적인 해결책은 공유 데이터를 사용하는 모든 클래스들이 하나의 공통 부모 클래스(“worker” 라 부르도록 하자)로부터 파생되는 형태이다. worker 클래스에는 lock()과 unlock() 메소드를 정의하여 작업의 시작과 끝에 이 메소드를 호출토록 하면 된다. 하지만 이런 형태는 다음과 문제들을 파생시킨다.
          1. Data 객체를 수정하는 모든 메소드들이 수행 전에 lock()을 호출하고, 수행 후에는 unlock()을 호출함을 보장한다.
          특정 메소드(ex. 객체 생성 과정 추적) 호출을 로깅할 경우 aspect가 도움이 될 수 있다. 기존 방법대로라면 log() 메소드를 만들어 놓은 후, 자바 소스에서 로깅을 원하는 메소드를 찾아 log()를 호출하는 형태를 취해야할 것이다. 여기서 AOP를 사용하면 원본 자바 코드를 수정할 필요 없이 원하는 위치에서 원하는 로깅을 수행할 수 있다. 이런 작업 모두는 aspect라는 외부 모듈에 의해 수행된다. 또 다른 예로 예외 처리가 있다. Aspect를 이용해 여러 클래스들의 산재된 메소드들에 영향을 주는 catch() 조항(clause)을 정의해 어플리케이션 전체에 걸친 지속적이고 일관적으로 예외를 처리할 수 있다.
  • DataStructure/Foundation . . . . 5 matches
          if(n%2) /* n이 홀수이면 */ // 재귀 호출을 썼습니다.
          * 이건 또 얼마전에 본 글인데.. 재귀호출은 가급적 쓰지 말라 하더군요. 저 자신도 엄청 싫어합니다.
          * 기본적으로 함수를 호출하는 것 자체가 하나의 Overhead이며, 재귀호출의 경우 계속 함수스택에 해당 함수코드부분이 쌓여나가는 것이므로, n 의 값이 커질 경우 메모리를 많이 이용하게 됩니다. 하지만, 재귀호출의 표현법은 일반 수열의 표현식을 거의 그대로 이용할 수 있습니다. 코드가 간단해집니다.
  • EffectiveSTL/Iterator . . . . 5 matches
         VIIT i(ri.base()); // 앞에서도 말했지만 reverse 시리즈의 base()메소드를 호출해주면 그냥 시리즈로 바뀐 반복자를 리턴해준다.
          * 어째 그림이 좀 이상하긴 한데..--; 각각의 반복자가 가르키는 위치를 나타낸 것이다. 보면 알겠지만 ri에서 base()를 호출해줬는데도 가르키는게 같지가 않다.
          * 삽입은 문제없이 되었지만.. 만약에 erase()를 호출한다면? 난 3을 지우고 싶은데 base()호출해서 iterator버젼으로 넣어주면 4가 날아갈 것이다. 어떻게 해야하는가?
         v.erase( (++ri).base() ); // 끝. 이러면 ri는 2를 가르키게 되고 base() 호출후 리턴되는 반복자는 3을 가르킨다. 그걸 지우면 된다.
  • Gof/Mediator . . . . 5 matches
         DialogDirect는 다이얼로그의 전체 행위를 정의한 추상 클래스이다. client들은 화면에 다이얼로그를 나타내기 위해서 ShowDialog 연산자를 호출한다. CreateWidgets는 다이얼로그 도구들을 만들기 위한 추상 연산자이다. WidgetChanged는 또 다른 추상 연산자이며, 도구들은 director에게 그들이 변했다는 것을 알려주기 위해서 이를 호출한다. DialogDirector subclass들은 CreateWidgets을 적절한 도구들을 만들기 위해서 override하고 그리고 그들은 WidgetChanged를 변화를 다루기 위해서 override한다.
         changed 는 director의 WidgetChanged 연산을 호출한다. Widget들은 자신의 director의 WidgetChanged 호출을 의미있는 이벤트를 알져주기 위해서 사용한다.
         Button은 그것이 눌러졌을 때, Changed를 호출하는 단순한 widget이다. 이는 HandleMouse를 구현함으로써 되어진다.
  • MFC/ObjectLinkingEmbedding . . . . 5 matches
          || OnChange() || 임베드된 객체에 변경사항이 존재하면 그 항목의 서버에 보고될 때 프레임웍에 의해 호출된다. 일반적인 경우는 임베드된 객체를 다시 그릴때이다. ||
          || OnGetItemPosition() || OLE객체가 표시되어야 하는 컨테이너의 클라이언트 영역의 직사각형을 얻기 위해 프레임웍에 의해 호출 ||
          || OnChangeItemPosition() || 엠베드된 객체의 범위가 편집 작업 동안 변경되었다는 것을 컨테이너에 알리기 위해 프레임웍에 의해 호출 ||
          || OnGetExtent() || 임베드된 객체의 실제 범위를 얻기 위해 프레임웍에 의해 호출되는 부분이다. ||
          || NotifyChanged() || 서버에서 객체가 변경되면, 이 객체를 임베드 하고 있는 모든 컨테이너에게 이를 알려 컨테이너가 OnChanged()를 호출하도록 한다. ||
  • MFC/ScalingMode . . . . 5 matches
         || WindowOrigin || 윈도우의 왼쪽 상당 논리 좌표. CDC::SetWindowOrg() 함수를 호출해서 설정 ||
         || WindowExtent || 논리 좌표 안에 지정되어 있는 윈도우의 크기. CDC::SetWindowExt()로 호출 ||
         || ViewportOrigin || 장치 좌표에 되어 있는 윈도우의 왼쪽 상단의 좌표. CDC::SetViewportOrg()로 호출 ||
         || ViewportExtent || 장치 좌표 단위의 윈도우의 크기. CDC::SetViewportExt()함수로 호출 ||
         CDC::SetWindowExt(), SetViewportExt()를 호출해도 아무런 변화가 생기지 않는다.
  • OurMajorLangIsCAndCPlusPlus/errno.h . . . . 5 matches
         ||4||int EINTR||가로채기 함수 호출;발생한 비동기 신호와 호출의 방해된 종료. 이럴 경우에 당신은 다시 호출을 시도해보라.||
         ||11||int EAGAIN||자원을 일시적으로 사용할수 없다.; 그 호출은 나중에 당신이 다시 재시도 할수 있도록 한다. 오 직 분기점에서 이러한 이유로 EAGAIN에러 코드를 리턴한다.||
         || ||int EBACKGROUND||GNU 시스템에서 어떤 오퍼레이션의 호출자가 터미날의 전면처리 그룹에 없을 때 서버지원 프로토 콜에 이 에러가 리턴된다. 사용자들은 보통 이 에러를 보지 못하는데 왜냐하면 함수들은 SIGTTIN 이나 SIGTTOU신호로 해석하여 읽고 쓰기 때문이다.||
  • WinampPluginProgramming/DSP . . . . 5 matches
         // 실제로 DSP 관련 처리시 호출되는 함수들.
          config, // config 시 호출 함수.
          init, // init 시 호출 함수
          modify_samples1, // DSP 처리시 호출 함수
          quit // quit 시 호출 함수
  • eclipse디버깅 . . . . 5 matches
         프로그램을 한 단계 진행하되, 메쏘드 호출부라면 실행 포인트를 메쏘드 안으로 옮긴다. 호출하는 메쏘드의 내부 동작을 확인하고 싶을때 사용한다.
         메쏘드 호출부라도 메쏘드 안으로 들어가지 않고 현재 코드에서 한 단계씩 진행한다. 호출하는 메쏘드 내부 동작에는 관심이 없고 현재 코드 블럭에 관심을 집중하고 싶을 때 사용한다.
         현재 메쏘드에서 리턴한 후 그 메쏘드를 호출부했던 곳에서 다시 멈춘다.
  • html5/canvas . . . . 5 matches
          * video 요소의 DOM 객체를 사용할 경우 drawImage()를 호출한 시점에서 재생되는 프레임을 그려준다.
          * 호출시 패스가 닫히지 않았더라도 자동으로 닫힌 상태로 만든다.
          * beginPath()를 호출하여 클리핑 영역을 해제할 수 있다.
          * save()로 저장한 상태는 스택에 쌓이고 restore()를 호출할때마다 스택의 탑에서부터 상태를 불러온다.
          * 캔버스가 가진 toDataURL()을 호출하여 캔버스 내용을 URL로 얻어올 수 있다.
  • 데블스캠프2005/RUR-PLE/정수민 . . . . 5 matches
          재귀호출이 되면 이렇게 해보려 했으나, 재귀호출이 안되길래 (정확히는 되는데 시작지점이 바뀐다는..) 재귀호출이 지원이 안되는줄 알았다오.
          //추신: 러플이녀석 재귀호출이 이상한 방식으로 이루어 지는것 같다오. C를 써온 사람의 입장에서 볼때 불편하다는..
         나도 이녀석 제귀호출이 C랑 똑같았어도 이렇게 오래걸리진않았다고 ;ㅡ;
  • 1002/Journal . . . . 4 matches
         그리고 접근을 했는데, 너무 알고리즘적으로 접근하려고 했다. (재귀호출을 이용하는 식으로.. 거의 일반화식에 가깝게) 초반 10분정도를 그정도 써먹으니 너무 시간이 아까워서, 일단은 abc 자체만 통과하기 위해 노력을 했다.
          ''psyco는 가장 바깥쪽 함수, 클래스만 바인딩해주면 해당 코드가 호출하는 다른 코드들은 직접 알아서 다 바인딩 해준다. 즉, main이라는 함수가 있다면 그것만 바인딩하면 프로그램 내의 모든 코드가 바인딩 되는 셈. --JuNe''
          * DesignPatterns 연습차 간단하게 그림판을 구현해봄. 처음 간단하게 전부 MainFrame class 에 다 구현하고, 그 다음 Delegation 으로 점차 다른 클래스들에게 역할을 이양해주는 방법을 써 보았다. 그러던 중 MFC에서의 WinApp 처럼 Application class 를 ["SingletonPattern"] 스타일로 밖으로 뺐었는데, 계속 Stack Overflow 에러가 나는 것이였다. '어라? 어딘가 계속 재귀호출이 되나?..'
         즉, Application Class 의 인스턴스가 만들어지기 위해선 MainFrame 클래스가 완성되어야 한다. 그런데, MainFrame 에서는 Application 의 인스턴스를 요구한다. 그렇기 때문에 Application의 getInstance를 호출하고, 아직 인스턴스가 만들어지지 않았으므로 또 getInstance 에선 Application 의 Class 를 새로 또 만들려고 하고 다시 MainFrame 클래스를 생성하려 하고.. 이를 반복하게 되는 것이였다.
  • AcceleratedC++/Chapter7 . . . . 4 matches
          // <noun-phrase> 와 같이 연결된 문법이 <noun> 인경우에는 재귀적 함수 호출을 통해서 마지막 단어까지 내려간다.
          // 마지막 단어까지 내려갓을 경우 재귀 함수를 호출하고 bracketed = false 의 조건이 되기 때문에 재귀 함수가 종료된다.
          재귀함수의 호출은 반드시 함수의 내부에 재귀호출을 탈출 할 수 잇는 코드가 존재해야한다. 그렇지 않을 경우 stack_overflow가 발생한다.
  • CppStudy_2002_1/과제1/Yggdrasil . . . . 4 matches
         int count=0;//함수가 호출된 횟수를 셈
          int input;//원하는 횟수만큼 호출하기 위해 입력을 받음
          cout<<"함수를 몇번 호출 합니까?";
          cout<<"당신은 지금까지 "<<n<<"번 함수를 호출 하셨습니다.\n";
  • Gof/Singleton . . . . 4 matches
         클래스를 사용하는 Client는 singleton을 Instance operation을 통해 접근한다. _instance 는 0로 초기화되고, static member function 인 Instance는 단일 인스턴스 _Instance를 리턴한다. 만일 _instance가 0인 경우 unique instance로 초기화시키면서 리턴한다. Instance는 lazy-initalization을 이용한다. (Instance operation이 최초로 호출되어전까지는 리턴할 unique instance는 생성되지 않는다.)
          * (c) C++ 은 global 객체의 생성자가 translation unit를 통하면서 호출될때의 순서를 정의하지 않는다[ES90]. 이러한 사실은 singleton 들 간에는 어떠한 의존성도 존재할 수 없음을 의미한다. 만일 그럴 수 있다면, 에러를 피할 수 없다.
         물론, 코드 어디에선가 클래스를 인스턴스화하지 않으면 생성자는 호출되지 않을 것이다. C++에서는 MySingleton의 static instance를 정의함으로서 이 문제를 잘 해결할 수 있다. 예를 들어, MySingleton 클래스의 구현부를 포함하는 화일에 다음과 같이 정의하면 된다.
         이 소스를 컴파일하면, outer class의 생성자를 호출하는 부분, 즉 Init()과 Destroy()에서
  • HanoiProblem/영동 . . . . 4 matches
          call Move ;Move함수 호출
         Move proc ;Move 프로시저(재귀호출되는 부분)
          ;(by와 to의 위치를 바꿔서 함수 호출)
          call Move ;Move(by, to, from) 호출
  • Linux/필수명령어/용법 . . . . 4 matches
         이것은 리눅스의 Boume 셸이다. sh를 사용하면 sh가 bash를 호출하여 실행한다. bash를 직접 사용하지 말고 sh를 사용하도록 하라.
         이것은 시스템이 처음 가동될 때 자동으로 호출된다. 이름은 file system check를 줄인 것으로, 파일 시스템을 스캔(scan)하여 일관성을 유지하고 있는가를 검사한다.
         시스템을 다운시키기 전에 버퍼에 있는 이미지를 반드시 디스크로 기록해야 한다. 그렇지 않으면 디스크는 기록된 정보의 이미지와 일치하지 않는 이미지를 가지게 될지도 모른다. 사실, 이것을 사용할 경우는 극히 드물다. 왜냐하면 shutdown등의 동작을 수행하면 그들이 자동적으로 sync를 호출하기 때문이다.
         사실상, compress의 -d 옵션을 사용하면 압축을 풀 수 있기 때문에 이 명령은 불필요하다. 하지만 옵션을 사용하는 것보다 의미있는 단어를 사용함으로 좀더 친숙하게 사용할 수 있다. uncompress는 자신이 압축 풀기 동작을 수행하는 것이 아니라 -d 옵션을 주어 compress를 호출한다. uncompress 자신의 파일 크기는 아주 적다.
  • MineFinder . . . . 4 matches
         위의 결과를 보면, 가장 많이 호출되어 시간을 점유하는 것은 GetPixel와 PumpMessage이다. mfc의 함수와 윈도우 메세지드리븐 방식에 대해서는 수정할 수 없다 하더라도, 해당 함수에 대해서 호출 횟수를 줄이는 방법은 강구해야 할 것이다.
         GetPixel 은 어디서 호출될까? Edit->Find in Files 를 하면 해당 프로젝트내에서 GetPixel이 쓰인 부분들에 대해 알 수 있다.
         즉, 저 함수들을 최적화 시키던지, 아니면 저 함수들이 호출되는 횟수를 줄여야 하는 것이다.
  • NSIS/Reference . . . . 4 matches
         함수는 Section과 비슷한 역할을 한다. 하지만, 다른 점이라면 함수는 installer 에서 직접 선택하여 호출하는것이 아니라, Section 에서 Call 명령어를 통해 호출되어 인스톨러의 기능의 일부들을 보충하는 역할을 한다. 그리고 특별한 경우로써, Callback Function들이 있다.
         || 함수중 'un.' 으로 시작하는 것들은 일반적으로 Uninstaller를 위한 함수들이다. Uninstall Section이 정의되어있지 않은 경우, 호출되지 않을 것이다.
         특정 이벤트 발생시에 호출되는 함수들이다.
  • PyUnit . . . . 4 matches
         testcase를 실행하는 방법은 후에 설명할 것이다. testcase 클래스를 생성하기 위해 우리는 생성자에 아무 인자 없이 호출해주면 된다.
         다행스럽게도 우리는 setUp 라는, testing framework가 테스팅을 할때 자동으로 호출해주는 메소드를 구현함으로서 해결할 수 있다.
         만일 setUp 메소드 실행이 성공되면, tearDown 메소드는 runTest가 성공하건 안하건 상관없이 호출될 것이다.
         각각의 테스트 수행을 위해 (우리는 나중에 다시 보겠지만), 각각의 테스트 모듈을 '호출할 수 있는' test suite 객체를 제공하는 것이 좋다.
  • WebGL . . . . 4 matches
         Attribute는 각 포인트 별로 전달되는 정보이고 uniform 은 전체에서 공통적인 정보이다. 일반적으로 Attribute는 각 정점의 위치 정보와 각 지점의 법선 벡터 정보를을 전달한다. uniform은 일반적으로 카메라의 위치나 환경광의 위치처럼 전체적인 것을 전달한다. Attribute나 uniform은 일종의 변수인데 핸들을 얻어와서 그것을 통해 값을 전달할수 있다. 즉 Atrribute나 Uniform은 Javascript측에서 쉐이더로 정보를 보내는 것이다. varying은 쉐이더 간의 정보 전달에 사용된다. vertex shader에서 fragment shader로 값이 전달되며 반대는 불가능하다(파이프라인 구조상 당연한 것이다). 이때 vertex shader는 각 정점(꼭지점) fragment shader는 각 픽셀에 한번 호출되게 되는데 각 정점 사이의 값들은 [보간법]을 거쳐 전달되게 된다(그라디언트 같은 느낌이다 중간값을 알아서 만들어 준다).
         각 정점(vertex, 꼭지점)마다 호출되며 주로 꼭지점의 위치를 연산하고 실제 View에 투영하는 연산을 주로 하게 된다. 한마디로 모델의 위치 변환과 카메라 시점에 따른 변환 원근법을 적용하는 변환등을 수행한다.
         각 정점 사이에 있는 픽셀 마다 호출된다. 주로 광원효과를 적용한 픽셀의 최종적인 색깔이나 텍스쳐 연산에 사용된다. varying변수를 vertex shader에서 fragment shader로 넘겨주면 각 정점 사이에는 보간법으로 변환된 값이 넘어 온다.
         현재 객체 래핑중 중대한 문제에 봉착. 대부분의 모듈과 세이더 코드는 [콜백]으로 호출되는데 이것을 적절히 래핑할 방법이 없다. webGL과는 하등 연관이 없는 부분이라서 각자 알아서 구현하도록 해도 되지만 대부분의 경우 같은 코드를 다스 짜고 있는 나를 보게 된다. 이것을 어떻게 해야 잘한 래핑이라 할수 있을까?
  • html5/drag-and-drop . . . . 4 matches
          * 드래그 중 마우스 포인터가 요소와 겹치는 순간 호출되는 이벤트이다.
          * 데이터를 꺼낼 때는 데이터 포맷 형식의 인수를 이용하여 getData()를 호출한다.
          * 이벤트 객체가 가진 stopPropagation() 메서드를 호출하여 막을 수 있다.
         || types ||setData()를 호출할 때 지정되는 포맷 문자열을 배열 형식으로 얻을 수 있다. ||
  • 데블스캠프2002/날적이 . . . . 4 matches
          * 세연 : 재귀호출이 익숙하지 않아서 연습해볼겸 랜덤워크를 재귀호출루 짰는데 다른 사람들 코드보니까 과연 나의
          하노이는 역쉬..... 재귀호출이 아직두 완전하지 않다는 걸 느끼면서 많이 헤매서 겨우 했는데, 그것두 도움을
          받아서 완성해서 많이 아쉽다. 언제쯤 재귀호출을 잘 다룰 수 있을지.....얼
  • 데블스캠프2005/게임만들기/제작과정예제 . . . . 4 matches
          블럭을 랜덤하게 호출하는 함수를 만들자. 그리고 그 안에 rand()함수를 사용해서, 임의의 숫자를 얻은후 그 숫자에 맞추어 블럭을 지정하고
          테스트를 위해서는 key_Left()와 같은 변수안에 넣고, 랜덤으로 만드는 함수를 호출한후, 호출해 보면 된다.
          다 만들어 진 후, 왼쪽, 오른쪽 방향키에 알맞은 인자를 넣어서 함수를 넣고, now_time()에 블럭을 아래로 내리는 함수를 호출하도록 하자.
  • 새싹교실/2012/ABC반 . . . . 4 matches
         라는 코드에서 myfunc함수를 호출하며 a,b를 파라미터로 넘겨주고 있다.
         함수의 선언은 그 함수를 호출하는 코드보다 위에 있어야 한다. 그렇기 때문에 위처럼 함수의 선언만 해놓고 실제 구현은 아래에다가 해놓는 경우가 많다.
         order에 1을 입력받으면 add함수를 호출해 두 수를 더하고
         order에 2를 입력받으면 sub함수를 호출해 두 수를 뺍니다.
  • 2학기파이선스터디/서버 . . . . 3 matches
          # 접속 요구가 들어오면 호출된다.
          # 접속 요구가 들어오면 호출된다.
          # 접속 요구가 들어오면 호출된다.
  • AcceleratedC++/Chapter14 . . . . 3 matches
          -> 연산자는 일견 이항 연산자 처럼 보이지만 동작하는 방식이 다른 연산자들과는 다르다. ->를 호출하게 되면 연산자의 좌측요소에서 포인터를 대신해서 사용이 가능한 요소가 리턴된다.
         왜냐하면 Student_info에 대해서 내부 객체를 변경하는 함수는 오직 read인데 우리의 경우에는 read 함수 호출시 기존의 내부 멤버를 소멸시키고, 다시 객체를 만들어서 할당하기 때문이다.
         '''호출 객체의 변화가 같은 요소를 가리키는 핸들들에게 영향을 주지않기를 바라는 regrade 함수'''
  • AcceleratedC++/Chapter8 . . . . 3 matches
         WikiPedia:Generic_function : 함수를 호출하기 전까지는 그 함수의 매개변수 타입이 무엇인지 알 수 없는 함수.
         WikiPedia:Generic_function : 함수의 호출시 인자 타입이나 리턴타입을 사용자가 알 수없다. ex)find(B,E,D)
         함수의 호출시 함수의 매개변수를 operand로 하여 행해지는 operator의 유효성을 컴파일러가 조사. 사용 가능성을 판단
  • Chapter I - Sample Code . . . . 3 matches
          // PUSHF는 CPU레지스터를 하나씩 일일이 스택에 넣는 작업을 간편하게 하기 위하여 호출 하는 ASM명령으로 정해진 순서에
          수행시간 측정은 한 task 의 수행시간을 측정하기 위해서 한다. (당연한거 아냐?). 이 측정은 PC의 82C52 타이머 2번을 통해 수행된다. 수행시간 측정을 위한 함수로는 PC_ElapsedStart()와 PC_ElapsedStop()이 있다. 하지만 이 두 함수를 사용하기 전에 PC_ElapsedInit()를 호출해야한다. 이 함수는 두 함수와 관련된 오버헤드를 측정하는데 사용된다. 이렇게 하면 PC_ElapsedStop 함수에 의해 수행시간이 리턴된다(마이크로세컨드). 이 두 함수는 모두 리엔터런트(주 : 몇 개의 프로그램이 동시에 하나의 task나 subroutine을 공유하여 쓰는 것에 대해 말함, from 한컴사전) 하지 않아야한다. 다음은 PC_DispChar()함수의 측정시간을 구하는 예이다.
          '''uCOS-II를 끝내기 전에 PC_DOSSaveReturn 함수를 호출해야한다. 그렇지 않으면 DOS가 curruped mode 가 되어버리고 이것은 당신의 windows에 영향을 줄 수도 있다.'''
  • DoubleBuffering . . . . 3 matches
          // TODO: 여기에 특수화된 코드를 추가 및/또는 기본 클래스를 호출합니다.
         // Timer가 호출하는 함수 내부
          * 이렇게 Timer내부에서는 메모리 DC에다 다 그려주고, Invalidate(FALSE)를 호출합니다. FALSE 이거 중요합니다.
  • EightQueenProblemDiscussion . . . . 3 matches
         직접 다시 새로 시작하는 것에 대해서는 비교계산을 내리기 힘들것 같네요. (더 좋은 디자인을 얻어내는 것과 훈련라는 점에서는 물론 저도 추천) 제가 잘못했다고 생각되는 부분은, 퀸을 배열하는 방법 알고리즘 부분에 대해 TestDrivenDevelopment 를 지키지 못했다는 점이죠. (머릿속에 먼저 재귀함수 호출 등의 특정 알고리즘들이 먼저 떠오른지라. )
         즉, 실제 Queen의 위치들을 정의하는 재귀호출 코드인데요. 이 부분에 대한 TestCase 는 최종적으로 얻어낸 판에 대해 올바른 Queen의 배열인지 확인하는 부분이 되어야 겠죠. 연습장에 계속 의사코드를 적어놓긴 했었는데, 적어놓고 맞을것이다라는 확신을 계속 못했죠. 확신을 위해서는 테스트코드로 뽑아낼 수 있어야 할텐데, 그때당시 이 부분에 대해서 테스트코드를 못만들었죠.
         사고의 도구로써는 연습장과 TFP 둘 다 이용했지만, 순수하게 적용하지는 않았습니다. (위의 Queen을 놓는 부분에 대한 재귀호출부분에서는 적용못함) 테스트작성시간/코드작성시간 등에 대한 관리는 하지 않았습니다. (이 부분에 대해서는 반성을. ^^;) 흠.. 그리고 'The Simplest Thing'을 찾아나갔다기 보다도, 이미 해당 문제에 대해서 의사코드를 생각하고, 해당 코드에 대해 Top-Down 형태로 모듈을 나눈뒤에 모듈에 대해 테스트를 만들어갔다는 생각이 드네요. --석천
  • Gof/Command . . . . 3 matches
         어플리케이션은 각각의 구체적인 Command 의 subclass들로 각가각MenuItem 객체를 설정한다. 사용자가 MenuItem을 선택했을때 MenuItem은 메뉴아이템의 해당 명령으로서 Execute oeration을 호출하고, Execute는 실제의 명령을 수행한다. MenuItem객체들은 자신들이 사용할 Command의 subclass에 대한 정보를 가지고 있지 않다. Command subclass는 해당 request에 대한 receiver를 저장하고, receiver의 하나나 그 이상의 명령어들을 invoke한다.
          * invoker는 command에서 Execute를 호출함으로서 request를 issue한다. 명령어가 undo가능할때, ConcreteCommand는 명령어를 undo하기 위한 state를 저장한다.
         MyClass의 instance로 있는 Action을 호출할 command를 만들기 위해서, 클라이언트는 단순히 이렇게 코딩한다.
  • Gof/Facade . . . . 3 matches
         Parser는 점진적으로 parse tree를 만들기 위해 ProgramNodeBuilder 를 호출한다. 이 클래스들은 Builder pattern에 따라 상호작용한다.
         ProgramNode의 각 subclass들은 ProgramNode의 child인 ProgramNode 객체를 호출하기 위해 Traverse operation을 구현한다. 매번 각 child는 children에게 같은 일을 재귀적으로 수행한다. 예를 들어, ExpressionNode는 Traverse를 다음과 같이 정의한다.
          RepairFault 명령은 page fault 인터럽트가 일어날때 호출된다. Domain은 fault 를 야기시킨 주소의 메모리객체를 찾은뒤 RepairFault에 메모리객체과 관계된 캐쉬를 위임한다. Domain들은 컴포넌트를 교체함으로서 커스터마이즈될 수 있다.
  • HardcoreCppStudy/두번째숙제/This포인터/김아영 . . . . 3 matches
         f()로 클래스 내부에선 호출이 가능한데 정확히 this->f()에서 this가 생략된 형이다.
         class A에서 class B의 내부함수를 호출하는데
         class A에서 class B의 내부함수 호출시에 this라는 인자를 넘겨준다.
  • Java Study2003/첫번째과제/노수민 . . . . 3 matches
          네이티브 메서드는 자바 언어 말고 다른 언어로 된 메서드를 호출해서 수행하는 메서드이다. 이러한 메서드도 자바가상머신에서 처리한다.
         <APPLET>~</APPLET> 태그를 이용하여 HTML 페이지 내에 포함되어, 자바 호환 웹 브라우저에 의해서 실행되도록 작성된 자바 프로그램입니다. 다시 말해서, 여러분의 홈 페이지 내에 삽입되어 자바 호환 웹 브라우저에 의해 실행되도록 규약에 맞추어 작성된 자바 프로그램을 말하는 것입니다. 다음에 나오는 그림은 자바 애플릿의 실행 과정을 자세히 보여주고 있습니다.
         다른 자바 프로그램에 의해 삽입(import)되어 사용될 수 있도록 작성된 자바 프로그램입니다. 이러한 자바 패키지는 기존의 프로그래밍 언어에서 사용하던 라이브러리 또는 운영체제에서 제공해 주는 API 등과 같다고 볼 수 있습니다. 자바 패키지 역시 해당 규약을 갖겠지요. 자바에서는 기본적으로 압축 파일의 형태로 'casses.zip"이라는 자바 패키지가 제공되고 있고, 압축 파일 내에는 디렉토리 단위로 패키지가 포함되어 있다.
  • MFCStudy_2001/MMTimer . . . . 3 matches
          * uDelay : 타이머가 호출될 간격을 넣습니다. 단위는 ms입니다.
          * fuEvent : 타이머가 호출되는 방법을 넣습니다.
          * 5는 타이머가 호출될 간격입니다. 역시 단위는 ms(1/1000초)입니다.
  • MoreEffectiveC++/Basic . . . . 3 matches
         위의 두번째 호출의 클래스 상속의 다형적 성질을 이용한 함수 이용 즉
         역시나 이것도 '''delete'''에 관한 모호성을 제공한다. 문제시 되는 점은 rawMemory상에 배치된 EquipmentPiece의 '''destructor''' 호출 유무이다. 예상대로 '''destructor'''를 강제 호출해 줘야 한다. 그래서 위가 아니라, 이런식의 삭제가 된다.
  • MoreMFC . . . . 3 matches
         떡하니 source를 보면 어떻게 돌아가는 거야.. --; 라는 생각이 든다.. 나도 잘모른다. 그런데 가장 중요한것은 global영역에 myApp라는 변수가 선언되어 있다는 사실이다. myApp 라는 instance가 이 프로그램의 instance이다. --a (최초의 프로그램으로 인스턴스화..) 그리고, CWinApp를 상속한 CMyApp에 있는 유일한 함수 initInstance 에서 실제 window를 만들어준다.(InitInstance함수는 응용 프로그램이 처음 생길 때, 곡 window가 생성되기전, 응용 프로그램이 시작한 바로 다음에 호출된다) 이 부분에서 CMainWindow의 instance를 만들어 멤버 변수인 m_pMainWnd로 pointing한다. 이제 window는 생성 되었다. 그렇지만, 기억해야 할 것이 아직 window는 보이지 않는다는 사실이다. 그래서, CMainWindow의 pointer(m_pMainWindow)를 통해서 ShowWindow와 UpdateWindow를 호출해 준다. 그리고 TRUE를 return 함으로써 다음 작업으로 진행 할 수 있게 해준다.... 흘. 영서라 뭔소린지 하나도 모르겠네~ 캬캬.. ''' to be continue..'''[[BR]]
         그리고, 그 다음으로 진행되는 것이. CMainWindow에 있는 OnPaint라는 함수. window의 client 영역에 무언가를 그리는 함수가 호출된다. (그 전에 이것 저것 많이 있겠지만... 뭐 매크로를 통해 messagemap 관련 entry라던지.. 이런것들을 선언해 주는 작업.. --a) 그래서, DrawText를 이용해 화면 중앙에 "Hello, MFC"를 그린다. 그러면 이 프로그램의 기능(?)은 끝이다.[[BR]]
  • PowerOfCryptography/허아영 . . . . 3 matches
          음.. 잘짯네.^^ 근데 temp라는 전역변수 없어도 되는거 아니냐?ㅎ 아웅 복잡해~>ㅁ<;; 그리궁..재귀호출인듯..ㅎ 꼭 재귀호출 안써도 될것 같은데 말야.^^ 잘못하면 스택오버플로우의 압박이..;;ㅁ;; 아닌가?ㅎ~~>ㅃ<;;;; ㅎㅎ 그럼 조은하루~!^^* - [조현태]
          재귀호출은.. 생각난 대로 한건데, 스택오버플로우 되냐? ㅡㅜ -- 아영
  • Ruby/2011년스터디/세미나 . . . . 3 matches
          * 아.. 세미나가 끝나니까 할말이 생각나네요..ㅠㅠ 루비의 블록 넘기기는 사실 블록이 yield구문에게 전달되는 것이 아니라 yield를 만나면 함수의 호출부로 컨트롤이 이동해 블록이 있는지 확인하고 실행합니다. 책에서는 co-routine 이라고 이해하면 된다는 설명이 있어요~ 블록이 전달되는게 아니라 컨트롤 플로우가 왔다갔다!! 스위치 태스킹처럼요. 세미나때 설명을 잘 해드렸어야 했는데 죄송천만번입니다 - [서지혜]
         }}} 윗줄 아랫줄 모두 문제 없이 실행되지. 이 경우는 의도가 명확한 경우야. 그런데 이 add 메서드를 호출해서 3, 4, 7을 더한 값을 알고 싶다면
         }}} 이렇게 메서드를 중첩해서 호출해야겠지? 이 때 괄호를 사용하지 않으면 다음과 같이 쓸 수 있어.
  • TellVsAsk . . . . 3 matches
         당신이 구현하려는 logic 은 아마도 호출된 객체의 책임이지, 당신의 책임이 아니다. (여기서 you 는 해당 object 를 이용하는 client. caller) 당신이 object 의 바깥쪽에서 결정을 내리는 것은 해당 object 의 encapsulation 에 위반된다.
         object and then calling different methods based on the results. But that may not be the best way to go about doing it. Tell the object
         아마 당신은 이렇게 말할지도 모른다. "나는 그런 코드를 작성한 적이 없어!" 하지만, referenced object 의 값을 조사해서 그 결과값에 따라 각각 다른 메소드를 호출하는 식으로 적당히 구현하며 얼머무리는 경우는 흔하다.
  • TestFirstProgramming . . . . 3 matches
         후자의 경우는 해당 코드의 구조를 테스트해나가는 방법으로, 해당 코드의 진행이 의도한 상황에 맞게 진행되어가는지를 체크해나가는 방법이다. 이는 MockObjects 를 이용하여 접근할 수 있다. 즉, 해당 테스트하려는 모듈을 MockObject로 구현하고, 호출되기 원하는 함수들이 제대로 호출되었는지를 (MockObjects 의 mockobject.py 에 있는 ExpectationCounter 등의 이용) 확인하거나 해당 데이터의 추가 & 삭제관련 함수들이 제대로 호출되었는지를 확인하는 방법 (ExpectationList, Set, Map 등의 이용) 등으로서 접근해 나갈 수 있다.
  • ZeroPage_200_OK . . . . 3 matches
          * 자바스크립트에서 자주 this 얘기가 나오던데, 이번에 이야기를 들을 수 있어서 좋았습니다. 개인적인 느낌을 말하자면 함수가 데이터로 취급되는데 함수 내부에서 함수를 호출한 객체(execution context)의 정보를 사용하기 위해서 this를 사용한다는 느낌이는데 맞는지 모르겠군요. p.print를 넘기는 것도 실제로 class p에 있는 함수를 넘기는 게 아니라 p.print에 바인딩 된 어떤 함수를 넘기는 것이니까 내부의 this가 기존 OOP와 같이 해당 class의 인스턴스는 될 수 없겠죠. 그리고 제일 마음에 들었던 것은 역시 예전에 했던 스터디에서 다뤘던 자바스크립트의 네 가지 특징에 대해서 들을 수 있었다는 점이었습니다. 사실 예전 스터디 떄 무척 듣고 싶었는데 개인적인 사정으로 참가를 할 수 없어서 꽤 아쉬웠던 터라 ;;; 마지막에는 개인적인 사정으로 시간이 안 맞아서 좀 급하게 나갔는데, 그래도 최대한 들을 수 있는 데까지 듣기를 잘 한 것 같은 느낌이 들었습니다. - [서민관]
          * 웹 초기에 css설명했을 때 css셀렉터 문법도 설명을 해주셨었는데 많이 까먹어서 헷갈렸었습니다. -_- 역시 한 두 번 본걸로는 금방 잊어버리기 쉬운 것 같습니다. jQuery함수의 대부분은 호출 후 jQuery객체를 리턴하기 때문에 함수의 체이닝이 가능하다는 얘기를 하셨었는데 구글의 guava도 그렇고 요즘은 이런 형태의 구현이 많은건지 궁금합니다. 그리고 결과 값을 받아서 계속해서 다른 작업을 하는 경우가 아니라면 체이닝이나 그냥 한 번에 계산하는 방식이나 별 차이가 없는건가요? - [서영주]
          * data() 메소드 - 이벤트 핸들러에 클로저를 쓰면 핸들러가 등록되었을 시점과 핸들러가 호출되었을 시점의 변수 값이 다를 수가 있다. 클로저를 쓰지 않기 위해서는 .data()를 이용하면 해당 data가 key/value 형태로 DOM트리에 등록된다.
  • ZeroPage_200_OK/note . . . . 3 matches
          * 3. 실행문맥을 instance로 한 생성자를 호출한다.
          * 실제 호출해야 하는 함수를 찾는 과정
          * 이때의 규약을 CGI라 부른다.
  • 새싹교실/2011/AmazingC/6일차 . . . . 3 matches
          * 함수의 선언부: 반드시 함수 호출하기 전에 선언을 해놓아야 한다!!
          * sum2의 경우 호출시 메인함수 위에 선언이 되어있나 확인한 다음 sum2의 정의부를 실행한다!!
          * 함수의 recursive호출
  • 새싹스터디2007/영동 . . . . 3 matches
          * 재귀호출
         ||이름||a의 b승||피보나치수열||팩토리알(재귀호출)||피보나치수열(재귀호출)||
  • 임인택/삽질 . . . . 3 matches
          * C++ 에서 SingletonPattern 을 적용했는데.. 소멸자가 호출되지 않는것 같다.. 프로그램 종료시에 인스턴스를 강제로 삭제하였다. - 타이머 루틴에서 instance() 를 얻어왔는데. 타이머는 KillTimer 직후에 소멸되지 않는다.. 이로 인해.. 인스턴스가 삭제 된 후에 다시 생성되었었다...
         someFunc(t1, t2); //와 같은 식으로 호출했다 수많은 런타임에러를 만남. 결국
         someFunc(&t1, &t2); // 이렇게 호출함으로써 해결.
  • 토비의스프링3/오브젝트와의존관계 . . . . 3 matches
          * 사용자 정보를 저장할 때 자바빈 규약을 따르는 오브젝트를 이용하면 편리하다.
          getBean()메소드 : ApplicationContext가 관리하는 오브젝트를 요청하는 메소드. ""안에 들어가는 것은 ApplicationContext에 등록된 빈의 이름. 빈을 가져온다는 것은 메소드를 호출해서 결과를 가져온다고 생각하면 된다. 위에서는 userDao()라는 메소드에 붙였기 때문에 ""안에 userDao가 들어갔다. 메소드의 이름이 myUserDao()라면 "myUserDao"가 된다. 기본적으로 Object타입으로 리턴하게 되어있어서 다시 캐스팅을 해줘야 하지만 자바 5 이상의 제네릭 메소드 방식을 사용해 두 번째 파라미터에 리턴 타입을 주면 캐스팅을 하지 않아도 된다.
          * @Configuration이 붙은 클래스는 애플리케이션 컨텍스트가 활용하는 IoC 설정정보가 된다. 내부적으로는 애플리케이션 컨텍스트가 @Configuration클래스의 @Bean메소드를 호출해서 오브젝트를 가져온 것을 클라이언트가 getBean() 메소드로 요청할 때 전달해준다.
  • 하노이탑/윤성복 . . . . 3 matches
          Mcount++; //함수가 호출될때 마다 1씩 증가
          hanoi(disk-1,start,finish,other); // 큰원반을 뺀 위에 것들을 other 기둥으로 옮기는 재귀함수 호출
          hanoi(disk-1,other,start,finish); // other 기둥에 있는 것을 finish 기둥으로 옮기는 재귀함수 호출
  • 02_Python . . . . 2 matches
         호출 함수 실행 stdout.write("spam, ham.toast\n")
         호출 myfunc("spam, ham, toast\n")
  • 05학번만의C++Study/숙제제출/2 . . . . 2 matches
          * 평상시에는 문자열의 주소를 하나의 전달인자로 취하여, 그 문자열을 한 번 출력하는 함수를 작성하라. 그러다가 0이아닌 int형 값을 두 번째 전달인자로 제공하면, 그 시점에 도달할 때까지 그 함수가 호출되었던 횟수만큼 그 문자열을 반복해서 출력한다. (문자열이 출력되는 횟수는 두 번째 전달인자의 값이 아니라 그 함수가 호출되었던 횟수와 같다.)물론 이 함수는 거의 쓸모가 없다. 하지만 이것은 이 장에서 설명한 몇 가지 프로그래밍 기술을 사용할 것을 요구한다. 이들 함수를 사용하여 함수의 작동을 보여 주는 간단한 프로그램을 작성하라
  • 5인용C++스터디/에디트박스와콤보박스 . . . . 2 matches
          m_Edit가 CEdit의 포인터로 선언되었으므로 일단 new 연산자로 CEdit객체를 만든다. 그리고 이 객체의 Create 멤버함수를 호출하여 에디트를 생성한다. Create 함수의 원형은 다음과 같다.
          이렇게 Create 함수로 만든 에디트의 통지 메시지는 어떻게 처리해야 할까. 클래스 위저드가 메시지 핸들러를 만들 때 해주는 세가지 동작을 프로그래머가 직접 해줘야 한다. 우선 메시지 맵에서 메시지와 메시지 핸들러를 연결시켜 준다. ON_EN_CHANGE 매크로에 의해 IDC_MYEDIT 에디트가 EN_CHANGE 메시지를 보내올 때 OnChangeEdit1 함수가 호출된다.
  • 5인용C++스터디/키보드및마우스의입출력 . . . . 2 matches
          키보드 메시지에서는 str배열에 문자열을 집어 넣기만 하며 문자열을 화면으로 출력하는 일은 WM_PAINT에서 맡는다. 단 키보드 메시지에 의해 문자열이 다시 입력되더라도 화면상의 변화는 없으므로 WM_PAINT메시지가 발생하지 않는다. 그래서 강제로 WM_PAINT 메시지를 발생시켜 주어야 하는데 이 때는 InvalidateRect 함수를 호출해 주면 된다. WM_CHAR에서 문자열을 조립한 후 InvalidateRect 함수를 호출해 주어 키보드가 입력될 때마다 화면을 다시 그리도록 하였다.
  • CleanCode . . . . 2 matches
          * Java Proxies : 객체 생성 시에 proxy를 거치게 하는 방법을 통해 해당 객체의 메소드 호출시 다양한 부가 작업들(횡단 관심사)을 처리할 수 있다. 다만 사용이 복잡하고 사용시에도 아래의 방법들에 비해 제한이 좀 있다.
          alert(arguments[0]); // 이렇게 apply의 앞 혹은 뒤로 실행되기를 원하는 기능을 호출한다.
  • ComponentObjectModel . . . . 2 matches
         There exists a limited backward compatibility in that a COM object may be used in .NET by implementing a runtime callable wrapper (RCW), and .NET objects may be used in COM objects by calling a COM callable wrapper. Additionally, several of the services that COM+ provides, such as transactions and queued components, are still important for enterprise .NET applications.
         RCW를 구현하고 있는 .Net 하에서는 COM 객체는 아마도 제한적으로 호환성의 측면에서 사용될 것이다. 또한 .NET 객체들은 아마도 COM callable wrapper를 호출하는 것 때문에 COM 객체들안에서 사용될 것이다. 덧붙여서 COM+가 제공하는 일부분의 서비스들(transaction, queued components)은 여전히 .NET 응용프로그램에서도 중요한 부분이다.
  • DPSCChapter3 . . . . 2 matches
          하지만, 두 경우에 자동차를 생성하기 위한 코드와 그것의 컴포넌트 하위 부분은 여전히 같다. 즉, 모든 CarPartFactory 클래스들은 동일한 메시지 프로토콜을(다형성)을 구현하기 때문에, 팩토리 클라이언트는 팩토리 타입이 무엇인지 상관하지 않고 호출을 할 수 있다. 그것은 단지 팩토리 프로토콜에 의해 제공되는 일반적인 메시지를 전송한다.
          따라서, CarAssmebler를 만들기 위한 자동차 종류가 무엇이고 그 하위 부분들이 무엇을 해야하고, 그것의 실제 부분의 인스턴스가 무엇을 수행해야 할지를 결정한다. ABSTRACT FACTORY 해결은 우리가 CarAssembler 객체 밖의 모든 행동들을 추상화시킨다. 그리고 팩토리로 분리한다. 특별한 자동차 팩토리로 CarAssembler 확인을 한 후에, CarAssembler는 간단하게 구체적인 자동차와 하위 부분을 만들기 위한 팩토리를 호출한다.
  • DebuggingSeminar_2005/DebugCRT . . . . 2 matches
         || _CRTDBG_CHECK_ALWAYS_DF || _CrtCheckMemory() 함수를 모든 new, delete 함수에 대해서 자동 호출 되도록 지정한다.[[BR]] 이 함수는 할당된 공간의 유효성을 지속적으로 체크한다. 즉 domainerror나 기타 메모리 access에 관한 부분을 검사한다. 대신 오버헤드가 상당하다. 그러나 그만큼 디버깅의 효율성을 높여줄 수 있다. ||
         || _CRTDBG_LEAK_CHECK_DF || 프로그램이 종료되는 시점에서 _CrtDumpMemoryLeaks()를 호출. 메모리 해제에 실패한 경우 그 정보를 얻을 수 있다. ||
  • EffectiveSTL/ProgrammingWithSTL . . . . 2 matches
         // 메소드 호출 버젼
         // 알고리즘 호출 버젼
  • EightQueenProblem/임인택 . . . . 2 matches
          처음에 시작 call 을 좀 이상하게 한다. loop 을 돌면서 첫번째 라인의 원소에 대한 get_Queen()함수를 호출한다. 생각에는 get_Queen(0,0); 처럼 호출하는게 가장 이상적이라고 생각하는데..--;
  • EightQueenProblemSecondTryDiscussion . . . . 2 matches
         우.. 그리고 여전히 테스트 코드를 생각하기 어려웠던 부분이 실제 Queen 을 놓는 부분인데요. 다음과 같이 코드를 나열하고 재귀호출 부분에 대해서 유도를 하는 방법을 시도해봤습니다. 일종의 수열 찾는 방법이 되더군요. 음.. 이 부분에 대해서는 EightQueenProblem 에 대한 하나의 해를 알아놓고 시작한다면 TDD를 시도할 수 있을것 같다는 생각이 들긴 하는데. (문제는, 답을 구해놓고 나서야 이 생각이 났더라는. --;)
          예를 들어, Board 객체는 Queen 객체들을 만들고 배치, 자신의 상태를 출력하는 서비스를 지원하고, Queen 객체는 내가 다른 Queen 객체를 공격할 수 있는지 없는지 알려주는 서비스를 지원합니다 -- 더 나아가서 스스로 자기 앉을 자리를 찾아갈 정도로 똑똑하게 만들 수도 있겠죠. Queen 오브젝트 갑이 Queen 오브젝트 을에게 물어봅니다. "내가 너를 귀찮게 하고 있니(attackable에 대한 메타포임)?", 라는 부분은 OOP로 어떻게 표현될 수 있을까 직접 생각해 보는 것이 더 좋을 것 같습니다. OOP에서 객체끼리의 의사소통은 보통 메쏘드 호출로 이루어지고, 목적어는 인자의 형태로 전달된다는 점을 고려한다면 여러가지 방법이 떠오를 수 있겠죠.
  • Gof/Adapter . . . . 2 matches
          * 해당 클래스를 이용하는 Client들은 Adapter 인스턴스의 operation들을 호출한다. adapter는 해당 Client의 요청을 수행하기 위해 Adaptee 의 operation을 호출한다.
  • HanoiProblem . . . . 2 matches
         재귀함수가 사용되는 대표적인 예 몇가지를 보여줍니다. 재귀함수 사용에도 그 종류가 다른데, 대표적인 종류들을 보여주는 것이 중요합니다. "아, 재귀함수라는 것이 이렇게도 사용될 수 있구나!" 퍼뮤테이션/콤비네이션, 피보나치수열, 트리검색, 팩토리알, 조건문과 재귀호출로 반복문(while) 만들기 등이면 충분하지 않을까 합니다.
         그리고 재귀함수를 만들 때 유의점과 사고보조물을 가르쳐 줍니다. 유의점이라면 재귀함수는 리턴되는 값의 종류(타입)가 모두 동일해야 한다는 것, 재귀호출을 벗어나는 지점 근방에서 유의해야 한다는 점 등이고, 사고보조물로는 스택의 상태를 그림으로 그리는 방법이나, 수식을 사용하는 방법 등이 있겠죠.
  • HardcoreCppStudy/첫숙제/Overloading/변준원 . . . . 2 matches
         C++의 새로운 특징 중 하나인 디폴트 전달인자를 살펴보자. 디폴트 전달인자는 함수의 호출에서 대응되는 실제 매개변수를 빠뜨렸을 때 자동적으로 사용되는 값이다.
         다음은 함수의 다형성에 대하여 알아보자. 디폴트 전달인자는 개수를 변화시켜 가면서 같은 함수를 호출하게 했다. 함수의 다형성은 함수의 재정의라고도 하는데, 이는 여러 개의 함수가 같은 이름을 사용할 수 있게 해준다. ‘다형성’이라는 표현은 많은 형태를 가질 수 있게 해 준다.
  • HolubOnPatterns/밑줄긋기 . . . . 2 matches
          * 좋은 클래스는 getter와 setter메소드를 갖지 않는데, 이런 메소드는 구현 상세를 노출시키기 때문에 결과적으로 유지 보수를 어렵게 만들기 때문이다. 예를 들어 getter 메소드의 리턴 타입이 바뀌게 되면 getter를 정의하는 객체뿐 아니라 'getter'를 호출하는 모든 코드 또한 바꾸어 주어야 한다. 잠시 후에 getter와 setter 메소드 없이 시스템을 디자인하는 방법에 대해 설명할 것이다. 기대해도 좋다.
          * 재귀를 이용한 구현에서는 노드에 대한 레퍼런스가 각 재귀 호출의 로컬 변수이기 때문에 이를 유지하기 매우 쉽다.
  • Java Study2003/첫번째과제/곽세환 . . . . 2 matches
         <APPLET>~</APPLET> 태그를 이용하여 HTML 페이지 내에 포함되어, 자바 호환 웹 브라우저에 의해서 실행되도록 작성된 자바 프로그램입니다. 다시 말해서, 여러분의 홈 페이지 내에 삽입되어 자바 호환 웹 브라우저에 의해 실행되도록 규약에 맞추어 작성된 자바 프로그램을 말하는 것입니다. 다음에 나오는 그림은 자바 애플릿의 실행 과정을 자세히 보여주고 있습니다.
         다른 자바 프로그램에 의해 삽입(import)되어 사용될 수 있도록 작성된 자바 프로그램입니다. 이러한 자바 패키지는 기존의 프로그래밍 언어에서 사용하던 라이브러리 또는 운영체제에서 제공해 주는 API 등과 같다고 볼 수 있습니다. 자바 패키지 역시 해당 규약을 갖겠지요. 자바에서는 기본적으로 압축 파일의 형태로 'casses.zip"이라는 자바 패키지가 제공되고 있고, 압축 파일 내에는 디렉토리 단위로 패키지가 포함되어 있습니다. 다음에 나오는 그림은 JDK 1.2.2 에서 제공되는 패키지를 보여주고 있습니다.
  • JavaScript/2011년스터디/3월이전 . . . . 2 matches
          * 함수 안에 익명함수 중복으로 쓸 경우 즉시 호출하거나 변수에 넣어 호출 가능하게 만들어야 한다.
  • JavaScript/2011년스터디/CanvasPaint . . . . 2 matches
          //마우스를 이동할때마다 호출.
          //마우스를 이동할때마다 호출.
  • JavaStudy2004/오버로딩과오버라이딩 . . . . 2 matches
          위에서 말한 People클래스의 move함수를 예를 들어보겠다. 위의 move함수는 정수형 인자를 매개변수로 받아들인다. 만약 people.move(1.1, 2.13)라는 명령어를 실행한다면 매개변수의 타입이 다르다는 에러가 발생할 것이다. 더블 형의 인자를 받아들이기 위해 move함수를 Overloading한다. move(double aX, double aY){this.position.x += (int)aX;this.position.y += (int)aY;} 두 함수 다 유효한 함수로 사용된다. 두 함수 중 어떤 함수가 호출될 것인지는 매개변수 값에 의해서 결정된다. 즉 오버로딩 된 함수들은 반드시 매개변수의 타입이 달라 서로 구별될 수 있어야 한다.
         people.move(5.1,11.8);//Overloading된 함수 호출, 이동 후 위치(115, 121)
  • JavaStudy2004/클래스상속 . . . . 2 matches
          메소드도 비슷하게 작동한다.새로운 객체는 상위클래스의 모든 메소드 이름을 액세스한다. 그러나 메소드가 호출될 때마다 동적으로 메소드 정의가 선택된다. 특정 객체에 대한 메소드를 호출하면 자바는 제일 먼저 그객체 클래스의 메소드 정의를 살펴본다. 그 객체 클래스에 정의되지 않았다면 그 메소드 정의를 발견할 때까지 상위클래스를 찾게될 것이다.
  • MFC/DynamicLinkLibrary . . . . 2 matches
          프로그램이 먼저실행되데 DLL은 프로그램의 요청이 발생한 시점에서 메모리에 로드된다. 그때가 되서야 프로그램은 DLL로부터 함수의 어드레스를 얻고 그것을 사용해서 함수를 호출한다.
          독립적 실행은 불가능하지만 main함수의 변형된 형태를 포함한다. 이 곳에서는 dll이 사용되기 전에 초기화되는 내용들이 포함되게 된다. DLL초기 로드시 운영체제가 호출한다.
  • MobileJavaStudy/Tip . . . . 2 matches
          * System.gc() 함수를 호출하며 가비지 콜렉터를 명시적으로 수행해 준다.
         {{{~cpp destoryApp}}} 메소드에는 {{{~cpp unconditional}}} 이라는 {{{~cpp boolean}}} 값이 있다. {{{~cpp MIDlet}}}이 더 이상 필요하지 않거나 종료되어야 할 때 {{{~cpp DestoryApp}}} 메소드가 호출되고 {{{~cpp MIDlet}}}이 {{{~cpp Destroyed}}} 상태로 들어가게 되는데, 만약 {{{~cpp MIDlet}}}이 중요한 과정을 수행중이라면 {{{~cpp MIDletStateChangeException}}}을 발생시켜 그 과정이 끝날때까지 {{{~cpp Destroyed}}} 상태로 가는 것을 막을 수 있다. 하지만 이런 요청도 상황에 따라 받아들여지지 않을 수 있는데, {{{~cpp unconditional}}} 이라는 값이 그 상황을 알려준다. {{{~cpp unconditional}}}이 {{{~cpp true}}} 인 경우에는
  • MockObjects . . . . 2 matches
         사용 예2) Datatbase 와 관련된 프로그래밍에 대해서 UnitTest를 할때, DB Connection 에 대한 MockObject를 만들어서 DB Connection을 이용하는 객체에 DB Connection 객체 대신 넣어줌으로서 해당 작업을 하게끔 할 수 있다. 그리고 해당 함수 부분이 제대로 호출되고 있는지를 알기 위해 MockObject안에 Test 코드를 넣어 줄 수도 있다.
         || ExpectationCounter || 해당 함수의 기대하는 호출횟수를 카운트 하기 위한 도움 클래스 ||
  • MoreEffectiveC++ . . . . 2 matches
         - 가상 함수 호출과 파라미터 패스의 차이 이해
          * Item 12: Understand how throwing an exception differs from passing a parameter or calling a virtual function [[BR]] - 가상 함수 부르기나, 인자 전달로 처리와 예외전달의 방법의 차이점을 이해하라.
  • NSIS . . . . 2 matches
         사용 예 : exec 로 regsvr32.exe 호출시 비동기 호출이 되어 뒤의 delete 문이 실행된다. 이를 방지하기 위한 방법으로 다음과 같이 한다.
  • OpenGL스터디_실습 코드 . . . . 2 matches
          //repaint by calling callback function
          //repaint by calling callback function
  • OurMajorLangIsCAndCPlusPlus/signal.h . . . . 2 matches
          || SIGABRT || 그 프로그램과 abort가 호출되면 발생 ||
          || int __cdecl raise(int) || 이 함수를 호출한 프로시져에 첫번째 인자에 시그널번호에 해당하는 시그널을 보낸다. 실패하면 0이 아닌값을 리턴하는데, 오직 유효하지 않은 시그널 번호에서만 실패하게 된다. ||
  • PairProgramming . . . . 2 matches
         나는 .NET의 System.Data의 구조를 보고 즉시 PHP에 적용시키고 싶어졌다. ASP.NET에는 SqlConnection , OdbcConnection , OleDbConnection을 제공해 준다. 이 클래스들을 잘 사용하면 DataTier의 종류가 바뀌어도 코드의 수정을 최소화 시킬 수 있다. PHP는 여러가지 종류의 데이타베이스 관련함수를 제공해준다. 어떠한 데이타베이스를 사용하느냐에 따라 동일한 기능을 하는 다른 이름의 함수를 호출해야만 한다.
         하나의 클래스를 구현하고 구현된 하나의 클래스에서 switch로 호출되어야 하는 함수를 결정하면 된다는 것이었다.
  • RealTimeOperatingSystemExam2006_2 . . . . 2 matches
          b) 세마포 구현 어떤 코드에서 OSSched() 를 호출하고 나서 무슨 코드가 있는지 나옴. 대략 타임아웃으로 돌아온건지, 아니면 세마포를 얻는건지 관련 코드
          c) OSMemCreate 관련 한문제. 함수 바디를 쓰라는건지, 함수호출부분을 작성하라는것인지는 정확히 기억안남.
  • RefactoringDiscussion . . . . 2 matches
         위의 (1)번 코드는 원래처럼 그대로 두거나, usageInRange(Integer.MIN_VALUE, 100)으로 호출하는게 맞을 듯 하다.
         > 호출하는게 맞을 듯 하다.
  • STL/vector/CookBook . . . . 2 matches
          // 순회하면서 showMember 메소드 호출하고
          * 노파심에서 말하는 건데.. 함수로 객체를 넘길때는 꼭 참조! 참조! 입니다. 값이 안 바뀌면 꼭 const 써주시구여. 참조 안 쓰고 값 쓰면 어떻게 되는지 이펙티브 C++에 잘 나와 있습니다.(책 선전 절대 아님) 복사 생성자를 10번 넘게 호출한다는 걸로 기억함.
  • Spring/탐험스터디/wiki만들기 . . . . 2 matches
          * RequestMapping의 method 타입을 이용해 signup 페이지 호출과 실제 signup을 구분하여 핸들링
          * 이건... 음.. "signup 폼을 담은 페이지를 호출" 할 때와 "사용자의 ID와 PASSWORD를 전달해 로그인 처리를 하는" 경우가 같은 Request Name을 가지게 되서..
  • TddWithWebPresentation . . . . 2 matches
         즉, 일종의 Template Method 의 형태로서 Testable 하기 편한 ViewPageAction 의 서브클래스를 만들었다. 어차피 중요한것은 해당 표현 부분이 잘 호출되느냐이므로, 이에 대해서는 서브클래스로서 텍스트를 비교했다.
          2. MockPresenter 를 만든다. 중요한 것은 출력결과를 테스트하는것이 목적이 아니라 action 결과 행해지는 일들(Transaction)이 제대로 일어났는지를 테스트하는 것이다. MockPresenter 는 그냥 해당 메소드들이 호출되었는지만 verify 하는정도면 충분할 것이다.
  • Trace . . . . 2 matches
         ( {{{~cpp TRACE}}} 매크로가 내부적으로 함수 호출을 하는것 같기는 한데 생각해보면 {{{~cpp TRACE}}} 매크로보다 우리가 정의한 함수를 호출하는게 조금더 오버헤드가 있을것 같다 )
  • django/ModifyingObject . . . . 2 matches
         Employee 모델에 해당하는 새로운 객체를 만들고 save메소드를 이용하면, 데이터베이스에 새로운 레코드를 삽입하거나, 기존의 레코드를 갱신한다. 기존에 삽입하지 않았기 때문에 처음 save를 호출하면 레코드를 삽입하고, 다음 번 save를 호출하면 레코드를 갱신한다. 레코드는 객체로, 레코드의 속성을 객체의 멤버 변수로 취급한다.
  • html5/communicationAPI . . . . 2 matches
          * start() : 포트를 이용할 수 있도록 한다. 채널 메세징 수행시 각각의 포트에 대해 start()를 호출
          * onmessage : 메세지 도착시 이벤트 핸들러가 호출
  • java/reflection . . . . 2 matches
          * classpath를 이용해 현재 프로젝트내의 class가 아닌 외부 패키지 class의 method를 호출하는 방법.
          * jar파일에 존재하는 class를 현재 프로젝트에서 동적으로 호출할 수 있다.
  • 데블스캠프2011/다섯째날/HowToWriteCodeWell/정의정,김태진 . . . . 2 matches
          elevator.callElevatorUp(40); //엘리베이터 밖에서 호출된 층으로 오도록 하는거.
          elevator.callElevatorDown(70); //엘리베이터 밖에서 호출된 층으로 오도록 하는거.
  • 레밍즈프로젝트/프로토타입/MFC더블버퍼링 . . . . 2 matches
         Test는 OnDraw 상에서 하였다. OnDraw는 Invalidate를 통해서 OnPaint가 호출되면 자동으로 호출된다.
  • 바퀴벌레에게생명을 . . . . 2 matches
         다큐에서 CBug타입의 멤버 변수를 생성한다. 그리고 뷰에서 방향키의 키이벤트(OnKeyDown)를 받으면 다큐의 CBug 타입의 멤버 변수의 Move함수를 호출하고 변경된 position과 direction을 OnDraw에서 받아서 알맞은 그림을 잘라내서 뷰에 그린다.
         다큐에 RandomWalking함수를 제작하고 뷰에서 스페이스바의 키이벤트가 일어나면 0.3초의 타이머가 생성(OnTimer)되어 RandomWalking함수를 0.3마다 호출하고 변경된 위키와 방향대로 뷰에 그려준다.(OnDraw) 다시 스페이스바를 누르면 움직임을 멈춘다.
  • 상협/삽질일지/2002 . . . . 2 matches
          ''Exception Handling 에 대해서 이해해야 할 것 같은데. Exception 은 해당 함수가 throws 등으로 발생을 시키고, Java 의 경우 그 Exception 을 반드시 처리를 해주는 곳을 만들어야 하지. 해당 메소드 내에서 Exception 이 발생은 하는데, 그 메소드에서 예외처리를 바로 하고 싶지 않으면 (즉, 그 Exception을 그 메소드 내에서 처리하지 않고, 그 메소드를 호출했던 곳 등에서 처리를 한다고 한다면) throws 로 해당 메소드에서 exception 을 또 던져주는 식으로 되겠지. 만일 Class.forName(...) 쓴 구문을 try - catch 로 예외를 또 잡는다면 이야기가 다르겠지만. 자바는 Exception 를 강요하는 관계로 예외는 catch 에서 무엇을 하건, 반드시 해당 발생된 예외를 잡아줘야 함. (그 덕에 최악으로 뻗을 일이 적지. 예외는 발생하더라도) --석천''
          * 오늘도 어김 없이 ㅡㅡ;; 삽질을 했다. 이번에는 matrix 클래스를 구현하는데 matrix데이터를 이중 배열로 private영역에 넣어서 이것 저것 해보는데 나중에 클래스의 matrix 데이터를 호출해야할 경우가 생겼다. [4][4] 이거 두개로 리턴할라고 했는데 안되었다. 남훈이형이랑 제본뜬 책찾아 보니깐 배열은 리턴이 안된다고 나왔다. 그래서 고민하다가 *[4] 이거 두개(포인터형 배열 4개짜리)를 사용하고 나중에는 *를 리턴하는 식으로 돌파구를 찾았다.(*[4] 이것도 배열이랑 비슷하게 써먹을수 있었다. 예-> *(matrix[0]+1)) 처음에는 뭔가 되는듯 싶었다. 클래스 내부 배열 설정도 제대로 되고 하였다. 그 .... 러..나.. ㅡㅡ;; 역시나 난 삽질맨이었다. 나중에 + 연산자 재정의 클래스 내에서 객체를 생성해서 리턴할때 뭔가 제대로 먹지가 않았다. 그거 가지고 간만에 ㅡㅡ;; 삽질에 바다에 퐁당 빠졌다. 간만에 해보는 삽질도 그리 유쾌한 일은 아니었다.. -_- 그렇게 계속 신나게 삽질하다가 도저히 안되겠다 싶어서 멤버 데이터를 public에 넣어 버리는 엽기적인 일을 해버렸다. ㅡㅡ; 그 방법밖에는 없는거 같았다. 그 후로는 아무런 걸림돌 없이 쭉쭉 되었다. 진작 이렇게 할걸하는 생각을 했지만 서도 멤버 데이터를 public안에 넣어서 웬지 모를 찝찝함이..
  • 새싹교실/2011/데미안반 . . . . 2 matches
          * [강소현] - 함수의 형태를 반환형이 있는 지의 여부와 매개변수가 있는 지의 여부에 따른 4 가지를 실습하여 차이를 알아보았습니다. 그리고 재귀함수에 대한 진도도 나갔으나, 아무래도 그냥 함수 한번 호출하고 끝낼 때보다 이해가 잘 가지 않는 듯 합니다. 다음 시간에 한번 더 복습할 예정입니다. 재귀함수로 만드는 factorial이나 gcd 같은 것을 점화식을 설명하고 보여주면 좀 더 이해가 쉽지 않을까 싶었습니다.
          * 함수 호출 시, stack에 돌아올 주소를 넣어두고 함수가 종료되면 stack에서 빼와서 돌아간다. LIFO(Last In First Out)의 순으로..
  • 새싹교실/2011/무전취식/레벨6 . . . . 2 matches
          * Factorial 짤때 중요한건 Stack Call!! 함수 호출시. 스택에 돌아올 주소를 넣어두고 함수가 종료되면 스택에서 빼와서 돌아간다. 너무 많은 자기 자신을 호출하는 함수라면 스택에 너무 많이 쌓여 오버 플로우(Over Flow)로 에러가 나게 된다. 항상!! 종료조건을 정하고 함수를 설계하자.
  • 새싹교실/2011/쉬운것같지만쉬운반/2011.3.23 . . . . 2 matches
         3. 나는 프로그램이 실행되고 CPU가 맨 먼저 호출하는 함수가 뭔지 안다! (O/X)
         c는 30이므로 비교 결과가 참이 되기 때문에 assert함수의 호출이 종료된다.
  • 새싹교실/2011/쉬운것같지만쉬운반/2011.5.17 . . . . 2 matches
         4. 함수를 호출할 때 변수의 값을 전달하는 방식
         5. 함수를 호출할 때 변수의 참조를 전달하는 방식
  • 새싹교실/2012/해보자 . . . . 2 matches
          2. swap(int num1, int num2)함수를 구현하시오. 함수 호출을 배우지 않았기 때문에, 그리고 포인터를 아직 배우지 않았기 때문에 기본적인 코드를 제공합니다.
          * 함수의 호출: 함수에게 매개변수 등을 넘겨주어 결과값을 기다리는 것.
  • 이영호/기술문서 . . . . 2 matches
         [http://bbs.kldp.org/viewtopic.php?t=24407] - Reference 에 의한 호출과 Pointer에 의한 호출 (결론: Reference는 포인터에 의해 구현되며 표현만 CallByValue 다.)
  • 정모/2006.5.22 . . . . 2 matches
          재귀호출, 자료구조, 알고리즘, 윈도우, 디버그, DB, MSDN, 아스키코드, 비트연산,
          - 수 : 자료구조, 재귀호출 / 상섭, 기웅, 보창, 성민
  • 코바예제/시계 . . . . 2 matches
         시간 객체에 대한 인터페이스는 ObjTimeServer이며 getTime()이라는 메소드를 가지고 있는데 getTime()는 문자 형식으로 현재의 시간을 반환해 준다. CORBA 객체를 작성하는 첫번째 단계는 인터페이스를 만드는 것이다. 인터페이스는 IDL로 작성되며 인터페이스는 IDL 컴파일러로 컴파일된다. 이 IDL 컴파일러는 기본적으로 사용자가 이용하는(예를들면 VisiBroker) ORB에 포함되어 있는 것이다. IDL로 작성된 인터페이스를 컴파일하면 컴파일러는 두 개의 코드 파일을 생성해 준다. 이 코드 파일들은 각 IDL 컴파일러가 사용하도록 약정된 프로그래밍 언어로 되어 있다. 여기에서 사용하는 ORB는 Java ORB이므로 코드 파일은 Java(Stub, Skeleton)로 되어 있을 것이다. IDL 컴파일러에 의해 생성되는 코드는 프록시 객체(proxy object) 및 스켈레톤 코드이다. 클라이언트는 프록시 객체를 사용하여 IDL로 표현된 인터페이스 타입의 객체 레퍼런스에 대한 호출을 생성한다. 바꾸어 말하녀 프록시 객체는 클라이언트가 작업을 위해 사용하는 대리("stand-in") 객체인데 원격 객체가 마치 지역 객체처럼 보이게 해준다는 것이다. 스켈레톤 코드는 이러한 인터페이스를 지원하는 객체에 액세스하기 위해 사용된다. 생성되는 코드는 위치 투명성을 구현한다. 위치 투명성을 통해 객체 레퍼런스를 변환하여 네트웍 연결을 퉁해 원격 서버로 보내며, 객체 레퍼런스에 대한 오퍼레이션에 따르붙는 파라미터를 ["마샬링"]하고, 이를 객체 레퍼런스가 지시하는 객체의 현재 메소드에 전달하여 메소드를 수행하고 그 결과를 반환하려고 하는 것이다. 바꾸어 말하면 클라이언트는 IDL 컴파일러에 의해 생성된 프록시 객체를 가지고 작업을 하는데, 그것이 마치 지역 객체로 작업하는 것처럼 보일 것이라는 의미이다. ORB와 통신하는 것이 프록시 객체의 임무이며 ORB는 네트웍 연결을 관리하고 파라미터를 실제 서버 함수에 넘겨주며 결과를 리턴한다. 이런 식으로 수행에 대한 투명성을 유지한다.
         클라이언트 구현은 기본적으로 다음 세 가지 단계를 통해 이루어진다. 먼저 CORBA 환경, 즉 ORB를 초기화한다. ORB를 초기화한다는 것은 ORB 의사 객체(pseudo-object)에 대한 객체 레퍼런스를 얻게 된다는 것을 의미한다. ORB가 '의사 객체'라 불리는 이유는 그 메소드가 런타임 시스템과의 통신을 통해 라이브러리의 형태로 제공되며, 의사 객체 레퍼런스는 CORBA 인터페이스 오퍼레이션에 대한 파라미터로 전달될 수 없기 때문이다. 그 다음 단계는 객체 레퍼런스를 얻는 것이다. 객체 레퍼런스는 불투명한 데이터 구조이다. 그러나 객체 레퍼런스를 문자열로 바꿈으로써 지속성을 가지게 될 수 있다. 이것은 '객체 레퍼런스의 문자열화'라 불리며, 그 결과 얻어지는 문자열을 일컬어 '문자열화 객체 레퍼런스'라고 한다.(IOR) 이 문자열화 객체 레퍼런스는 원래의 "유효한" 객체 레퍼런스로 다시 바뀔 수 있다. 이 과정은 CORBA, 즉 ORB 인터페이스에서 정의된 두 가지 오퍼레이션 object_to_string()과 string_to_object()를 이용하여 이루어진다. 모든 CORBA 2.0 호환 ORB는 상호 운용 가능한 문자열화 객체 레퍼런스를 실제 돌아가는 객체 레퍼런스로 바꿀 수 있다. 적절한 타입으로 객체의 범위를 줄이면 그러한 결과를 얻을 수 있다. 이러한 오퍼레이션을 'narrow'라 한다. ORB를 초기화하고 객체 레퍼런스를 얻은 후에야 CORBA 프로그래밍은 원래 의도한 표준 객체 지향 프로그래밍처럼 동작하게 된다. 클라언트가 객체의 메소드를 호출하게 되면, 실제로 그 메소드는 원격 객체와 함께 동작하지만 클라이언트가 보기에는 지역 객체와 함께 동작하는 것처럼 보인다.
  • 피보나치/조현태 . . . . 2 matches
          //피보나치를 연산합니다.재귀호출
          //안제귀호출..
  • 호너의법칙/박영창 . . . . 2 matches
         @return 호너함수의 재귀호출 값 + 호출 차수의 계수값
  • 후각발달특별세미나 . . . . 2 matches
         // foo(), bar() 가 호출될 때마다 memory사용량이 4K 씩 늘어난다.
         그런데, 함수 호출에 의한 오버헤드는 컴파일러/VM 기술이 발전하면서 점점 줄어들고 있고, 문제가 복잡할수록 그런 낮은 단계의 옵티마이제이션보다 높은 단계에서의 최적화가 훨씬 더 효과적인데, 리팩토링이 잘 되어 함수가 잘게 쪼개어져 있으면 높은 단계의 최적화를 하기가 쉬워집니다. (그래도 여전히 로우레벨의 옵티마이제이션이 필요하다면 매크로나 코드 제너레이션을 쓸 수 있습니다. DavidParnas의 [http://www.acm.org/classics/may96/ 논문] 참고)
  • 05학번만의C++Study/숙제제출/1 . . . . 1 match
         섭씨 온도를 전달인자로 전달받아 화씨 온도로 환산하여 리턴하는 사용자 정의 함수를 main() 함수가 호출하는 프로그램을 작성하시오. 프로그램은 섭씨 온도로 입력할 것을 요구해야 하고, 다음과 같은 실행 결과를 출력해야 한다. 참고로, 섭씨 온도를 화씨 온도로 변환하는 공식은 Fahrenheit = 1.8 X Celsius + 32.0 이다.
  • 05학번만의C++Study/숙제제출1/윤정훈 . . . . 1 match
          * 섭씨 온도를 전달인자로 전달받아 화씨 온도로 환산하여 리턴하는 사용자 정의 함수를 main() 함수가 호출하는 프로그램을 작성하시오. --[최경현]
  • 3N+1Problem/강희경 . . . . 1 match
         파이선으로 재귀호출을 한번 구현해보았으나, 엄청 느리다.
  • 5인용C++스터디/멀티미디어 . . . . 1 match
          SND_LOOP 플래그를 지정하면 반복적인 효과음이나 배경음악을 연주하는 등의 설정을 할 수 있을 것이다. 연주를 중지시키려면 PlaySound 함수의 첫 번째 인수를 NULL로 하여 다시 호출해 주면 된다. 따라서, 오른쪽 마우스 버튼을 누르면 연주가 중지될 것이다. 주의할 것은 SND_LOOP 플래그는 반드시 SND_ASYNC와 함께 사용해야 한다. 만약 동기화 연주방식으로 반복연주를 하면 무한 루프로 빠져버릴 위험이 있다.
  • AcceleratedC++/Chapter10 . . . . 1 match
          상기의 코드에서 프로그래머가 원한 기능은 get_analysis_ptr()을 호출하면 그 결과를 역참조하여서 const vector<Student_info>&를 인자로 갖고 double 형을 리턴하는 함수를 얻는 것입니다.
  • AcceleratedC++/Chapter6 . . . . 1 match
          * static 스토리지 지정자는 함수의 최초 생성시 저장공간에 단 한번만 할당되며, 다시 호출을 하여도 새로 할당되지 않는다.
  • ActiveTemplateLibrary . . . . 1 match
         ATL string의 형변환시에는 {{{~cpp USES_CONVERSION}}} macro를 형변환 전에 호출하여야함.
  • AppletVSApplication/상욱 . . . . 1 match
          - 애플릿은 같은 HTML 페이지에 있는 다른 애플릿의 public 메소드를 호출할 수 있습니다.
  • BasicJava2005/5주차 . . . . 1 match
          - static은 클래스에 종속되는 변수로 인스턴스명이 아닌 클래스명으로 호출된다.
  • BuildingParserWithJava . . . . 1 match
         3학년 1학기 ProgrammingLanguageClass에서 숙제로 파서를 만들면서 한계를 많이 느꼈었다. 가장 큰 문제는 모든 흐름이 함수 호출을 따라 흘러간다다는 것이었다. 어느 곳이 잘못되었는지 알기가 어려웠기 때문에 찾는데 무척 애를 먹었다. 문법을 하나 추가하는 작업도 매번 오래 걸렸다. 그러다 보니 평가에 중요한 예외처리를 할 시간이 많지 않았다.
  • BusSimulation/상협 . . . . 1 match
          //시키는 메소드를 호출한다
  • COM/IUnknown . . . . 1 match
         COM 객체를 다른 포인터에 할당하거나 NULL 로 초기화 할 때 호출하여 참조카운터를 올바르게 유지해야만 객체의 정상적인 소멸을 보장할 수 있다.
  • CollectiveOwnership . . . . 1 match
         Wiki:RefactorLowHangingFruit . 고쳐야 할 것이 많다면 오히려 조금씩 고치도록 한다(그리고 고치는 작업을 엔지니어링 태스크로 혹은 유저 스토리로 명시화해서 관리한다). 고치는 중에, 5분 정도의 단위로 테스트를 해봐서 하나도 문제가 없도록 고쳐 나가야 한다. 섬과 육지를 연결하는 다리가 있을 때, 이걸 새 다리로 교체하려면 헌 다리를 부수고 새 다리를 만드는 것이 아니고, 새 다리를 만든 다음 헌 다리를 부수어야 하는 것이다. {{{~cpp formatText(String data)}}}을 {{{~cpp formatText(String data,boolean shouldBeVeryFancy)}}}로 바꾸어야 한다면, {{{~cpp fancibleFormatText}}}를 만들고, 기존의 {{{~cpp formatText}}}를 호출하는 곳을 {{{~cpp fancibleFormatText(data,false)}}}로 하나씩 바꿔나가면서 계속 테스트를 돌려보면 된다. 이게 완전히 다 되었다고 생각이 들면 {{{~cpp formatText}}} 정의를 지워본다. 문제가 없으면 {{{~cpp fancibleFormatText}}}를 {{{~cpp formatText}}}로 rename method 리팩토링을 해준다. 하지만 만약 이 작업이 너무 단순 반복적인 경우에, 충분히 용기가 생기고, 또 확신이 들면 이 작업을 자동화할 수 있다(OAOO). 예컨대 IDE에서 지원하는 자동 리팩토링을 사용하거나, 정규식을 통한 바꾸기(replace) 기능을 쓰거나, 해당 언어 파서를 이용하는 간단한 스크립트를 작성해서 쓰는 방법 등이 있다. 이렇게 큰 걸음을 디디는 경우에는 자동화 테스트가 필수적이다.
  • ComposedMethod . . . . 1 match
         메세지를 보내는 데에는 시간이 걸린다. 즉 함수 호출에는 오버헤드가 뒤따른다. 그러므로 최고의 속도를 내려면 하나의 메소드에 모든걸 때려넣을 수도 있다. 하지만? 댓가는 클것이다.(인력낭비, 비구조적 프로그램 양산)
  • ComputerNetworkClass/Report2006/PacketAnalyzer . . . . 1 match
          // This socket MUST be bound before calling the ioctl
  • ConnectingTheDots . . . . 1 match
         BoardPanel.mouseReleased -> BoardPresenter.processClick -> Game.join 식으로 호출되며
  • CppStudy_2002_1/과제1 . . . . 1 match
          * 문제1번 : 여기서도 전역 변수를 많이 사용한거 같다. 이것은 피하는게 좋다. 여기서 함수가 호출한 갯수를 알아야 하는데 이때는 static 이라는 키워드를 사용하면 된다.
  • DataCommunicationSummaryProject/Chapter8 . . . . 1 match
          * 운영자 자신의 WAP 서비스에 접속하는 대신에, 사용자가 WAP gateway를 호출해서 거기에 직접 접근한다. 이것의 문제는 요청에 대한 요금이다. 운영자의 WAP 서비스가 싼데 비해서 WAP gateway에 접속하는데에는 음성전화와 같은 비용이 든다.
  • DataStructure/List . . . . 1 match
          /// 이부분에 메뉴를 넣든 함수 호출을 하든 마음대로..
  • Debugging . . . . 1 match
         || Call Stack Window || 함수 호출 경로를 보여줌 ||
  • DevPartner . . . . 1 match
         d) 프로그램을 종료합니다. -> 세션 윈도우가 뜨면서 함수 호출 상황을 보고서로 만들어 줍니다.
  • Eclipse . . . . 1 match
         || Ctrl+Alt+H || 메소드 호출 순서를 Tree로 보여준다. ||
  • EffectiveSTL/Container . . . . 1 match
          * 또 하나의 문제점, insert 메소드는 실행할때마다 새로운 공간을 할당하기 위해 하나씩 밀린다. 만약 컨테이너가 n개의 객체를 가지고 있고, 거기다 m개의 객체를 insert로 넣으면.. n*m만큼 뒤로 땡기느라 시간을 낭비하게 된다. int같은 기본 자료형이면 괜찮을지도 모르지만.. 만약에 객체가 큰 경우라면, 대입 연산자, 복사 생성자 이런것도 저만큼 호출하게 된다. 미친다.
  • EightQueenProblem/nextream . . . . 1 match
         처음엔 2차원 배열 메모리 공간을 두고 메모리 상에 체크해 가며 루프를 돌릴까 하다가 생각을 바꿔서 재귀호출을 이용하게 되었습니다. 첫 문제에서 일단 제일 첫 퀸은 무조건 (0,0) 이라고 고정하고 재귀를 두번째 퀸부터 돌렸는데, 오히려 나중에 이 생각이 두번째 문제 풀때 딱 한글자만 바꿔서 적응이 되는 것을 가능케 한것 같습니다.
  • Gof/Composite . . . . 1 match
         Picture 클래스는 Graphic 객체에 대한 포함관계를 정의한다. Picture 는 Picture의 children의 Draw 메소드를 호출하게끔 Draw 메소드를 구현한다. 그리고 Picture는 child와 관련한 명령어들을 알맞게 구현한다. Picture 인터페이스는 Graphic의 인터페이스를 형성하므로, Picture 객체는 다른 Pricture들을 재귀적으로 조합할 수 있다.
  • Gof/State . . . . 1 match
         상태-구체적 작업들이 수행된 뒤, 이 명령들은 TCPConnection 의 상태를 전환하기 위해 ChangeState 명령을 호출한다. TCPConnection 은 TCP 커넥션 프로토콜에 대해 모른다. TCP에 대한 각각의 상태전환과 행동들을 정의하는 것은 TCPState 서브클래스들이다.
  • Gof/Strategy . . . . 1 match
          * 모든 제공된 알고리즘에 대한 일반적인 인터페이스를 선언한다. Context는 ConcreteStrategy에 의해 구현된 알고리즘들을 호출하기 위해 이 인터페이스를 이용한다.
  • HardcoreCppStudy/두번째숙제/ConstructorAndDestructor/김아영 . . . . 1 match
         - 클래스의 객체가 생성될 때, 자동으로 호출
  • HelpOnConfiguration . . . . 1 match
         모니위키의 몇몇 플러그인중 외부 프로그램을 사용하는 프로그램은 환경변수 PATH를 참조하여 외부 프로그램을 호출하게 된다. 이때 PATH의 설정이 제대로 맞지 않아 외부 프로그램이 제대로 실행되지 않는 경우가 있다. 이 경우 config.php에서 `$path`를 고쳐보라.
  • HelpOnLinking . . . . 1 match
         /!\ 이 문법은 매크로 문법과 충돌합니다. 예를 들어 {{{[[Date]]}}}라고 링크를 걸면 Date가 링크가 되는 대신에, Date 매크로가 호출되게 됩니다. 따라서 영문으로 된 페이지 이름을 연결할 경우는 매크로 이름이 중복되어 있다면 이중 대괄호로 링크를 걸 수 없습니다.
  • HighResolutionTimer . . . . 1 match
         The '''QueryPerformanceCounter''' function retrieves the current value of the high-resolution performance counter (if one exists on the system). By calling this function at the beginning and end of a section of code, an application essentially uses the counter as a high-resolution timer. For example, suppose that '''QueryPerformanceFrequency''' indicates that the frequency of the high-resolution performance counter is 50,000 counts per second. If the application calls '''QueryPerformanceCounter''' immediately before and immediately after the section of code to be timed, the counter values might be 1500 counts and 3500 counts, respectively. These values would indicate that .04 seconds (2000 counts) elapsed while the code executed.
  • HowManyPiecesOfLand?/문보창 . . . . 1 match
         // 함수 호출이 모두 복사로 이루어지므로 성능이 크게 떨어진다.
  • InternalLinkage . . . . 1 match
          // friend 함수에서 호출된다.
  • Java Study2003/첫번째과제/방선희 . . . . 1 match
          프로그래밍을 할때 데이터베이스에 대한 접근이라든가 또는 다른 시스템에 대한 참조를 할때 굳이 그 시스템에 대해서 세세하게 알필요 없이 그저 외부에 주어진 인터페이스만을 이용해서 접근하면 됩니다. (예를 들자면 어떤 기능을 이용할때는 이런 메소드를 호출하면 된다. 어떤 값을 저장하기 위해서는 이런 메소드로 접근하면 된다 정도). 빈즈에 대한 내용은
  • Java/문서/참조 . . . . 1 match
         을 호출하는 경우에는 NullPointerException이라면서 에러 객체를 발생시킨다.
  • JavaStudy2003/두번째과제/곽세환 . . . . 1 match
         다른 객체 생성자 호출; // 반드시 첫번째 줄에서 이루어져야 함.
  • LIB_2 . . . . 1 match
         이럴 경우 컴파일을 해 보면 펑션의 호출이 RET가 아닌 IRET로 끝나게 된다.[[BR]]
  • LUA_6 . . . . 1 match
         __newindex : 새로운 index가 추가 되었을 경우에 호출 되는 meta 함수
  • LawOfDemeter . . . . 1 match
         the code, you can do so with confidence if you know the queries you are calling will not cause anything
  • Linux/MakingLinuxDaemon . . . . 1 match
         1. fork 호출하여 자식 프로세스 생성. 부모프로세스 종료
  • MFC/DeviceContext . . . . 1 match
         윈도우 운영체제에 의해서 정의된 데이터 구조. 윈도우 운영체제가 장치에 비종속적인 GDI 함수로, 출력 요청을 처리하는 출력장치에 대한 작업으로 해석가능하다. DC에 대한 포인터는 윈도우의 API함수를 호출함으로써 얻을 수 있다.
  • MFC/Print . . . . 1 match
          페이지 카운트를 계산한다. DoPreparePrinting() 호출
  • MFC/Socket . . . . 1 match
         ///클라이언트가 접속하는 경우 이벤트가 발생하여 아래 함수가 호출된다.
  • MFCStudy_2001/진행상황 . . . . 1 match
          * 1월 11일 - 멀티미디어 타이머 쓰다가 계속 에러가 난다. 자꾸 형이 틀렸다고 나오는데 열받아서 때려쳤다. 나중에 기분풀리면 다시.. 벽돌 즉각즉각 깨짐. 블록 두개에 동시에 부딪칠때도 같이 처리. 이제 95프로 정도 기본틀 완성. 죽을 때 처리만 해주 면 완성. 그 뒤로 미사일이나 아이템 넣고 싶으면 넣을 생각..-.- 100 프로 완성! 벽돌 다 깨지고 죽는거 처리돼고 어쨌든 지금 보기엔 완벽한것 같음. 앞으로는 좀더 이쁘게 다듬어볼 생각..~~ 멀티미디어 타이머를 쓴다고 써봤는데.. 확실히 바를 막 움직여도 공은 상관안하고 원래 속도 유지하면서 가긴 하거든요 근데 호출주기를 너무 줄여버리니까(1~20정도) 바가 움직이지 못하는 현상이... 끝낼때는 디버그 에러도 나더군요. 뭐 가 잘못된 건지..
  • MicrosoftFoundationClasses . . . . 1 match
          * {{{~cpp WinMain() 에서 Run() 호출. Run()은 메인 메시지 루프를 실행하게된다. (API에서 WinProc를 생각해보면 된다.)}}}
  • NSISIde . . . . 1 match
          * Save/Load 와 관련한 메세지의 함수 호출 순서 (Function Call 따라가기)
  • NotToolsButConcepts . . . . 1 match
          solve a problem that could be solved a lot more efficiently by calling
  • OpenGL스터디 . . . . 1 match
          * openGL에는 창관리, 상호 작용 인터페이스에 대한 어떤 함수도 없다. 이는 '''일반적인 임플리먼테이션(지정된 규약을 구현한 구현체)'''에 적용하기 위해서이다. Mac이나 리눅스 윈도우 각각 환경에 대해서 모두 접근이 가능케 하기위함이라고 간단히 말할 수 있다.
  • OurMajorLangIsCAndCPlusPlus/2005.12.22 . . . . 1 match
         - 함수 호출의 원리
  • OurMajorLangIsCAndCPlusPlus/locale.h . . . . 1 match
          /* setlocale()의 재호출 의해 변경될 것을 대비해 로케일 이름을 미리 복사해 둔다. */
  • PatternOrientedSoftwareArchitecture . . . . 1 match
          * 해결책(solution) : Blackboard 구조의 바탕에 깔린 개념은 공동의 데이터 구조에 대해서 협동적으로 작동하는 독립된 프로그램들의 집합이다. 그 독립적인 프로그램들은 서로 다른 프로그램을 호출하지 않고 또한 그것의 행동에 대해 미리 정의된 순서는 없다. 대신에 시스템의 방향은 주로 현재의 상태나 진행(progress)에 의해 결정된다. 데이터-관리 조종 체계(data-directed control regime)는 opportunistic problem solving 이라고도 불린다. moderator(중재자) component는 만약 하나 이상의 component가 contribution을 만들수 있다면 프로그램들이 실행되는 순서를 결정한다.
  • Postech/QualityEntranceExam06 . . . . 1 match
          3. Machine Language Like 한 프로그램 만들기. 코드 주고. 스앞 함수 호출하는 부분 있고 파라미터 패싱을 설명해야함.
  • PrimaryArithmetic/Leonardong . . . . 1 match
         이렇게 놓고 보니 수식과 비교해 이름을 잘못 지은 부분이 눈에 보인다. 아무튼 전단계 캐리를 구하는 부분을 그냥 작성하느라 흐름을 타지 못했다. 잘 돌아가는 프로그램을 만들었지만, 머리 속에 함수 재귀 호출을 계속 떠올리고 있었다. 수식이란 메타포가 있었는데도 구현을 하는데 메타포를 코드와 연결시키는데 오래 걸렸다. 아니 메타포를 생각하고 구현한 것이 아니다. 중복을 없애다 보니 그제서야 수식이 눈에 들어왔다.
  • ProjectPrometheus/CookBook . . . . 1 match
         getParameter 가 호출되기 전에 request의 인코딩이 세팅되어야 한다. 현재 Prometheus의 Controller의 경우 service 의 명을 보고 각각의 서비스에게 실행 권한을 넘기는데, 가장 처음에 request의 characterEncoding 을 세팅해야 한다. 차후 JSP/Servlet 컨테이너들의 업그레이드 되어야 할 내용으로 생각됨 자세한 내용은 http://javaservice.net/~java/bbs/read.cgi?m=appserver&b=engine&c=r_p&n=957572615 참고
  • PythonMultiThreading . . . . 1 match
         사용하는 방법은 매우 간단. Thread class 를 상속받은뒤 Java 처럼 start 메소드를 호출해주면 run 메소드에 구현된 내용이 multithread 로 실행된다.
  • Refactoring/MovingFeaturesBetweenObjects . . . . 1 match
         A client is calling a delegate class of an object.
  • ReplaceTempWithQuery . . . . 1 match
         수식을 뽑아내서 메소드로 만들고, 임시변수를 참조하는 곳을 찾아 모두 메소드 호출로 바꾼다. 새로 만든 메소드는 다른 메소드에서도 사용될 수 있다.
  • Ruby/2011년스터디 . . . . 1 match
          * 코드블록 { ~~ } 을 객체처럼 넘길 수 있음. 혹은 yield함수가 호출한다.
  • RubyLanguage/ExceptionHandling . . . . 1 match
          * 예외가 발생하면 예외 처리구문이 나올 때 까지 호출 스택을 타고 이동한다.
  • RubyLanguage/InputOutput . . . . 1 match
          * 단 예외 발생시 File.close는 호출되지 않는다. ensure 구문에서 처리할 수 있다.
  • ScheduledWalk/석천 . . . . 1 match
         4. 함수 호출뒤 return 값에 대해서 printf나 cout 등으로 결과값을 확인해보기.
  • Self-describingSequence/1002 . . . . 1 match
         binary search 로 바꾸고 나서도 역시 오래걸림. 다른 검색법에 대해서 생각하던 중, findGroupIdx 함수 호출을 할때를 생각.
  • SimpleDelegation . . . . 1 match
         // 채팅방에서 나가기 위해 호출되어야 할 메소드
  • StaticInitializer . . . . 1 match
         이를 방지하려면, StaticInitializer 를 일반 Method 로 추출한뒤, 생성자에서 이를 호출한다. (단, 인스턴스를 2개 이상 만드는 클래스인경우 문제가 있겠다.)
  • TCP/IP 네트워크 관리 / TCP/IP의 개요 . . . . 1 match
          *한 컴퓨터 내에서는 계층간에 데이터를 전달하는 방법에 대한 규약이 있어야함. 모든 계층이 연관되어 데이터를 전송하기 때문.
  • TddRecursiveDescentParsing . . . . 1 match
         문제점 : 테스트 가능할 수 있는 아이디어가 나오기까지가 오래걸렸다. 테스트 가능한 방법으로 접근하고 나서부터의 코딩은 1-1.5시간정도밖에 안걸렸지만. 그리고 본래의 스펙에는 AST 에 대한 언급이 없었다. 해당 함수가 제대로 호출되었는지를 근거로 접근하는 것이 나았을지도.
  • TestDrivenDevelopment . . . . 1 match
         테스트를 작성할때엔 '이미 완성되어있는 잘 된 API' 를 상상하며 작성한다. 잘 만들어진 API는 같은 일을 하더라도 직접 호출해줘야 하는 함수의 갯수가 적고 이해하기 편하며 '무엇'을 해주는지 그 메소드가 말해준다. 적게 코드를 써도 많은 일을 해주는것이다. 그리고, 테스트로서 컴퓨터의 컴파일러에게 코드작성을 위해 해야 할 일들을 묻고, 인터페이스를 만들고. 그리고 구현하고, 다시 구현된 코드를 Refactoring 한다.
  • UpdateWindow . . . . 1 match
         재귀함수가 실행될때마다 Invalidate()를 호출하도록 해 두었는데. 화면 갱신은 재귀함수가 끝난 경우에만 하고 있었다.
  • VendingMachine/재니 . . . . 1 match
          ''클래스 수가 많아서 복잡해진건 아닌듯(모 VendingMachine 의 경우 Requirement 변경에 따라 클래스갯수가 10개 이상이 되기도 함; 클래스 수가 중요하다기보다도 최종 완료된 소스가 얼마나 명료해졌느냐가 복잡도를 결정하리라 생각). 단, 역할 분담할때 각 클래스별 역할이 명료한지 신경을 쓰는것이 좋겠다. CoinCounter 의 경우 VendingMachine 안에 멤버로 있어도 좋을듯. CRC 세션을 할때 클래스들이 각각 따로 존재하는 것 같지만, 실제론 그 클래스들이 서로를 포함하고 있기도 하거든. 또는 해당 기능을 구현하기 위해 다른 클래스들과 협동하기도 하고 (Collaboration. 실제 구현시엔 다른 클래스의 메소드들을 호출해서 구현한다던지 식임). 역할분담을 하고 난 다음 모의 시나리오를 만든뒤 코딩해나갔다면 어떠했을까 하는 생각도 해본다. 이 경우에는 UnitTest 를 작성하는게 좋겠지. UnitTest 작성 & 진행에 대해선 ["ScheduledWalk/석천"] 의 중반부분이랑 UnitTest 참조.--["1002"]''
  • VisualBasicClass/2006/Exam1 . . . . 1 match
         ③ 함수는 수행한 결과를 호출한 프로그램에게 반한하는데 입력 인수는 여러 개일 수 있으나 출력 인수는 오직 하나이다.
  • VisualStuioDotNetHotKey . . . . 1 match
         ==== 함수툴팁 강제 호출 ====
  • Yggdrasil/가속된씨플플/0장 . . . . 1 match
          * 함수: 자신의 이름을 가지며, 다른 곳에서 이를 호출하거나 실행시킬 수 있는 프로그램의 한 조각
  • ZPBoard/AuthenticationBySession . . . . 1 match
         session_start(); // Session 을 사용하기 위해서는 반드시 맨 처음에 이 함수를 호출해주어야 한다.
  • ZeroPageServer . . . . 1 match
          * 가상 서버 할당은 slack에서 [bluemir]를 호출하시면 친절하게 도와드립니다.
  • ZeroPageServer/old . . . . 1 match
          * [http://www.robotstxt.org/wc/exclusion.html robot]규약 으로 엠파스의 침입을 막아야 한다. HowToBlockEmpas
  • ZeroWiki/제안 . . . . 1 match
          전 살아가는 것 자체가 크게 보자면 배우고, 발전(어떤 의미에서든)해가는 것이라고 생각합니다. 그런 의미에서 제 마음대로 위키를 사용하고 있었는데, 아무래도 하나의 사회에는 규약이란건 없더라도 지향하는 바는 있을거란 생각이 들어서 제안을 남겨 봤습니다. 전, ZeroWiki 가 nosmok 처럼 general purpose 해졌으면 합니다. --["zennith"]
  • html5/geolocation . . . . 1 match
          * clearWatch()가 호출되면 종료
  • html5/offline-web-application . . . . 1 match
         || updateready ||최신 캐시 얻기 완료. swapCache()를 호출할 수 있음 ||
  • html5/web-workers . . . . 1 match
          * 지역변수, 지역함수이므로 외부에서 호출 불가!
  • i++VS++i . . . . 1 match
          // 컴파일러는 내부적으로 operator++(0)을 호출한다.
  • ricoder . . . . 1 match
          serve(); // 메인 메뉴 호출
  • 그림으로설명하기 . . . . 1 match
         = 재귀호출 =
  • 김영록/연구중/지뢰찾기 . . . . 1 match
          마인없으면 찾는거.. 재귀호출 써먹으면 편하다우..ㅎㅎㅎ
  • 김태진/Search . . . . 1 match
         봉봉교수님이 내주신 연습문제에는 하나밖에 찾을 수 없는 구조인데, 함수에 check라는 static variable을 추가해서 그 함수가 호출되었을때 처음 찾은 값 다음부터 탐색하도록 하였습니다. thanks to. 힌트를 준 진경군.
  • 데블스캠프2002 . . . . 1 match
          1. ["Factorial"] - 재귀호출 을 알려주마. --zennith
  • 데블스캠프2003/둘째날/후기 . . . . 1 match
          * TDD와 페어프로그래밍으로 상욱이랑 미로찾기를 만들면서 많은걸 깨달았다. 가장 중요한건 네이밍의 중요성! 이름을 이상하게 지어놓고 이상한걸 호출하다가 자꾸 이상하게 나와서, 나중에는 '미로를 무시하고 이동한다.' 라는 말까지 나왔었다.--; 그러면서 중간에 TDD를 잘못했구나 아직 멀었구나 덜 테스트했구나하면서 좌절을 했지만 이름을 고치고 나니 바로 해결이 되는걸 보면서.. 아.. 더불어 CSP는 아직도 이해가 잘 안간다. --인수
  • 데블스캠프2004/금요일 . . . . 1 match
         ===== 마우스를 클릭했을 경우 paint 함수를 호출 =====
  • 데블스캠프2006/월요일/함수/문제풀이/성우용 . . . . 1 match
         3.난장이호출
  • 데블스캠프2006/준비 . . . . 1 match
         - 수 : 자료구조, 알고리즘, 재귀호출 / 상섭, 기웅, 보창, 성민, 민경 '''<- 여기에 알고리즘도 넣기로 한거 아니었나요?''' - [상규] - 맞아요
  • 데블스캠프2009/월요일후기 . . . . 1 match
          * [김준석] - 과거 06년도 데블스 캠프때 서버 할당받아서 svn잠깐 써보고 그다음에 전혀 써보지않았던 svn... 다시쓰기가 난감 할정도는 아니었지만 까는거에서 에러나면 어떻게 하는거야? 뭐여튼 nForge로 할당받아서 프로젝트 하나하나 올리면 되겠는데 문제는 이게 제로페이지 공용이라서 과연 학생들이 학업중 팀프로젝트때도 쓸려나.. 사용법을 가르쳐주는것 만으로 충분하긴 한데.. Zeropage내의 프로젝트는 얼마 되지 않는데;; 외부프로젝트라도.. 몇개나 올라올지는 모르겠지만 일단봐야지. 한 4~5개만 나와도 엄청난 프로젝트 갯수를 채우는 거겠군.. 프로젝트 진행중 중요한건 여러명의 개발자가 사용한 프로그램이기에 주석과 구조 그리고 변수건 함수건간에 서로 알아보기 쉽게 암묵적인 규약이라도 있어야된다는거 하긴 혼자할때는 그런거 필요없지만 SVN을 통해 올리는 프로젝트는 그렇게 해야 참고하고 구경하러온 학우들에게 도움이 될테니까. 특별히 코드레이스는 엄청나게 신경쓰면서 열심히 해봤는데 마지막에 올릴때 그것의 미인증이 인터넷을 막는 바람에 못올린것에 전산센터는 좀 반성해야되! 그리고 아쉬운점은 코드레이스는 좀더 늦게하고 제로페이지에 참가한 학우들에게 알고리즘이나 객체, 구조 함수에대해서 좀더 알려주고 조금 더 생각할 문제를 풀었으면 재밌었을텐데.. 난 printf()만 나오는 그리는 문제에는 잼병이란 말이다! 그렇다고 머리를 잘쓰는건 아니지만. 뭐.. 그렇듯 코드로 짜는건 빠른 손가락만 움직이면 되지만 푸는건 머리라는 사실은 변함이 없다. 코드레이스때 특정함수를 쓰게해서 DBMS나 라이브러리 북을 찾아보는 연습하는것도 좋았을텐데... 뒤에서 원그리고 있는데 앞에서 로보코드하고있을때는 안습. 끝나고 포트2 강추.
  • 데블스캠프2011/넷째날/Git/권순의 . . . . 1 match
          // 커맨드 함수 호출
  • 데블스캠프2012/둘째날/후기 . . . . 1 match
          * [변형진] - 현업 JavaScript 개발자 중에서도 이 정도로 언어를 설명할 수 있는 사람이 많지 않은데 꽤나 훌륭하게 설명했네요. 본격 JavaScript 공부를 원한다면 언제든 저를 호출하세요.
  • 레밍즈프로젝트/연락 . . . . 1 match
         니말대로라면 버튼리스트 클래스에다 버튼추가하는 함수만들어서 그거 호출하면 저절로 버튼리스트에 하나씩 추가되서 밖히는거잖아
  • 레밍즈프로젝트/이승한 . . . . 1 match
         프로그램 구조상 오류발견. 500*500정도의 맵에서 단순한 더블 버퍼링의 경우 초당 300만번 정도의 SetPixel이 호출됨-_-ㅋ
  • 무엇을공부할것인가 . . . . 1 match
          solve a problem that could be solved a lot more efficiently by calling
  • 문제풀이/1회 . . . . 1 match
          이런 경우를 개선하기 위해서 map 함수가 있는것입니다. 이를 Haskell에서 차용해와 문법에 내장시키고 있는 것이 List Comprehension 이고 차후 [http://www.python.org/peps/pep-0289.html Genrator Expression]으로 확장될 예정입니다. 그리고 print 와 ,혼용은 그리 추천하지 않습니다. print를 여러번 호출하는것과 동일한 효과라서, 좋은 컴퓨터에서도 눈에 뜨일만큼 처리 속도가 늦습니다. --NeoCoin
  • 방울뱀스터디/GUI . . . . 1 match
         Radiobutton 함수호출에서 indicatoron=0을 넣어주면 라디오버튼모양이 푸시버튼모양으로 된다.
  • 방울뱀스터디/Thread . . . . 1 match
         쓰레드를 사용하려면 : 쓰레드로 처리할 부분을 함수로 만들어주고 start_new_thread()로 그 함수로 호출하면 됩니다.
  • 새싹교실/2011/A+ . . . . 1 match
          메모리 보는법, 변수 조사 하는법 호출스택 쓰는법등을 배웠다.
  • 새싹교실/2012/AClass/3회차 . . . . 1 match
         malloc을 한 후에는 free을 호출해서 메모리에 할당하였던 것을 풀어주어야 한다. 그렇지 않으면 메모리에 남겨서 필요할때 사용할수가 없다.
  • 새싹교실/2012/startLine . . . . 1 match
          * 함수의 호출과 값 복사(call-by-value).
  • 새싹교실/2012/세싹 . . . . 1 match
          * 자세한 해결 방법입니다. 소켓을 생성하고나서 바로 setsockopt(mySocket, SOL_SOCKET, SO_REUSEADDR, &anyIntegerVariableThatContainsNonZero, sizeof(anyIntegerVariableThatContainsNonZero)); 함수를 호출하면 이 소켓의 생명이 다하는 순간 해당 포트에 자리가 나게 됩니다. - [황현]
  • 새싹교실/2012/아우토반/앞반/5.10 . . . . 1 match
          * 함수의 선언, 정의 호출의 의미
  • 새싹교실/2013/양반/3회차 . . . . 1 match
         함수호출
  • 서지혜 . . . . 1 match
          * [java/reflection] - java의 classLoader와 reflection을 이용해 외부 클래스 메소드 호출하는 법
  • 수학의정석/집합의연산/이영호 . . . . 1 match
         가만히 보니 재귀호출을 생각해볼 수도 있었겠다.
  • 쓰레드에관한잡담 . . . . 1 match
         Linux에서 멀티 프로세스 개념인 fork()는 내부적으로 do_fork()란 Kernel 함수를 호출하며, do_fork()는 내부적으로 user thread인 POSIX기반의 Mutex를 사용한다.
  • 영호의해킹공부페이지 . . . . 1 match
         which are pushed when calling a function in code and popped when returning it.
  • 위키를새로시작하자 . . . . 1 match
          음.. 저도 1'WIKI에 프로젝트 페이지를 옮기긴 했지만 좀 그랬습니다. 새로운 규약과 규칙이 만들어지자는 의견이 있는걸로 아는데요. 지금 0'WIKI의 내용을 옮겨 놓으면 그냥 예전의 위키가 되어버릴것 같습니다. 차라리 1'WIKI사용을 아직 하지 말로 나중에 시작하는건 어떨런지요? -[상욱]
  • 지금그때2006/여섯색깔모자20060324 . . . . 1 match
         장점 - 시간절약, 분위기 전환, 혼란이 없다, 호출이 용이, 강의실 백업 기능
  • 창섭/배치파일 . . . . 1 match
         현재 실행중인 배치 파일을 종료하지 않고 필요한 다른 배치파일을 호출하여 실행한 다음 원래의 배치파일로 다시 돌아오려고 할 때 사용됩니다.
  • 토이/숫자뒤집기/임영동 . . . . 1 match
          int reversedNumber=reverse(inputNumber);//뒤집을 숫자를 입력받고 reverse()호출
  • 튜터링/2011/어셈블리언어 . . . . 1 match
          * sum 프로시저를 만들어 재귀호출하기
  • 파스칼삼각형/김영록 . . . . 1 match
         int num_ret(int X, int Y) //재귀호출 1인경우(X=1,X=Y)엔 1을 리턴하는방식
  • 피보나치 . . . . 1 match
          기본적인 함수의 제작은 재귀호출로 만들어야 하나, 다른 방법을 사용해도 됩니다.
  • 피보나치/김민경 . . . . 1 match
         //재귀호출- 피보나치
  • 피보나치/김홍선 . . . . 1 match
         재귀호출로 만들려다가 상당히 이상하게 엉켜서 포기 ㅠ_ㅠ
  • 현종이 . . . . 1 match
          int GetTotal(); //점수합계를 호출하는 매써드입니다.
Found 252 matching pages out of 7540 total pages (5000 pages are searched)

You can also click here to search title.

Valid XHTML 1.0! Valid CSS! powered by MoniWiki
Processing time 1.8780 sec